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The  Fleet  Area  Control  and  Surveillance  Facility  FACS- 
FAC  located  at  North  Island,  San  Diego,  currently  performs 
its  data  collection,  storage  and  processing  functions 
manually.  Expected  expansion  of  the  scope  of  operations  at 
FACSFAC  will  overwhelm  the  present  system. 

This  thesis  develops  an  ORACLE-based  relational  data¬ 
base  system  for  use  by  FACSFAC.  The  systen  consists  of  two 
applications.  In  the  scheduling  application,  inputs  from 
various  sources  are  compiled,  allowing  both  a  powerful  query 
capability  and  the  production  of  a  weekly  schedule  of  ac¬ 
tivities  for  the  facilities  and  personnel  assignee  to  FACS¬ 
FAC.  The  exercise  results  application  provides  an  automated 
method  of  gathering  and  querying  pertinent  tactical  employ¬ 
ment  and  range  utilization  data  for  required  weekly,  monthly 
and  quarterly  reports. 

The  prototype  system  greatly  facilitates  the  storage, 
query  and  reporting  functions  of  the  organization  and  pro¬ 
motes  increased  efficiency  in  day-to-day  operations. 
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INTRODUCTION 


I  . 


A.  BACKGROUND 

The  Fleet  Area  Control  and  Surveillance  Facility  (FACS- 
FAC)  is  located  aboard  Naval  Air  Station  North  Island,  San 
Diego,  California.  It  is  a  command  of  the  U.S.  Navy  whose 
current  mission  is  to  provide  specialized  antisubmarine 
warfare  ( ASW )  and  electronic  warfare  (EW)  training  support 
at  the  Southern  California  Offshore  Range  (SCORE)  to  the 
operational  forces  of  the  Commander  in  Chief,  Pacific  Fleet 
( C I NCPACFLT ) .  In  executing  its  assigned  mission,  FACSFAC 
schedules  and  operates  the  range,  provides  for  simulated 
and/or  actual  submarine  targets,  monitors  the  performance  of 
units  exercising  on  the  range,  and  collects  and  analyzes 
tactical  data  from  fleet  units  conducting  training  on  the 
range.  When  weapons  and/or  simulated  targets  are  involved, 
F ACSF AC  pi'ovides  for  the  retrieval  of  those  assets  at  the 
completion  of  the  exercise.  Additionally,  FACSFAC  is  tasked 
With  the  safe  and  orderly  conduct  of  all  exercises  under¬ 
taken  on  the  various  SCORE  ranges . 

The  Southern  California  ASW  Range  (SOAR)  provides  "an 
instrumented,  three-dimensional,  in-air  and  underwater 
tracking  range"  [Ref.  i : pg .  1]  for  use  by  west  coost  air, 
surface  and  submarine  commands.  Presently,  the  112  square 
mile  range  is  capable  of  simultaneously  tracking  up  to  eight 
surface  and  air  platforms  and  four  in-water  vehicles. 
Planned  upgrades  to  the  range  include  expansion  to  600 
square  miles  in  area,  with  improved  track  resolution  and 
tracking  capability. 

The  EW  range  currently  provides  training  to  west  coast 
surface  ships  through  the  use  of  a  noise  jammer  simulation 
subsystem  and  a  temporary  radar  signal  simulator  (RSS-i9) 
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[Ref.  1 : pg .  1].  Training  opportunities  for  the  west  coast 
air  communities  are  also  being  explored.  Future  expansion  of 
the  EW  range  capabilities  will  include  threat  radar  simula¬ 
tion  and  participant  response  monitoring.  These  upgrades 
should  benefit  air  participants  and  attract  additional 
surface  units. 

As  SCORE  continues  to  evolve,  additional  ranges  and 
eguipment  will  become  available  to  support  train. ng  exer¬ 
cises  in  ASW,  EW,  Weapons  Impact  Scoring,  No-Drop  Laser 
Scoring  and  Naval  Gunfire  Support  (NGFS).  A  future  integra¬ 
ted  Range  Operations  Center  (ROC)  will  accommodate  a  wide 
range  of  exercise  scenarios  involving  multiple  warfare 
areas . 

B.  STATEMENT  OF  PROBLEM 

The  proposed  expansion  of  range  size  and  data  collec¬ 
tion  capabilities  will  overwhelm  the  manual  data  handling 
techniques  of  the  current  FACSFAC  management  information 
system.  Not  only  will  the  scheduling  process  become  more 
complicated  with  the  development  of  additional  ranges  and 
the  increased  utilization  of  those  ranges,  but  the  quantity 
of  tactical  data  collected  during  the  exercises  is  expected 
to  double.  Clearly,  the  present  manual  system  cannot  be  ex¬ 
pected  to  cope  with  this  growth.  Lack  of  an  automated  data¬ 
base  causes  an  inordinate  amount  of  time  to  be  spent  manual¬ 
ly  searching  files  for  data  required  for  the  various  re¬ 
ports.  Optional  data  manipulation  functions  are  not  being 
performed  by  the  Program  Engineers  due  to  the  tedium  as¬ 
sociated  With  the  file  searches.  These  optional  functions, 
consisting  mainly  of  tactical  employment  comparisons,  could 
be  of  significant  use  to  the  training  departments  of  the 
client  commands. 
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C .  SCOPE 

The  implementation  of  an  automated  database  to  gather 
and  store  schedule  and  exercise  results  data  and  to  create 
an  exercise  schedule  is  just  ohe  facet  of  the  integrated 
management  information  system  envisioned  by  FACSFAC.  The  ul¬ 
timate  goal  is  the  creation  of  the  Southern  California  Range 
Asset  Management  Network  (SCRAMNET),  comprised  of  worksta¬ 
tions  and  shared  peripherals  to  create  an  integrated  infor¬ 
mation  resources  system  for  the  SCORE.  The  SCRAMNET  will 
consist  of  three  major  components:  database  applications, 
the  hard ware / opera t 1 ng  system,  and  te x t / g r a ph i c s . 

The  database  applications  component,  called  the  South¬ 
ern  California  Range  Asset  Management  Database  (SCRAMBASE), 
IS  divided  into  an  Administration  database  (ABASE)  module, 
an  Equipment  database  (EBASE)  module,  and  an  Operations 
database  ( OBASE )  module. 


Figure  1,1  SCRAMBASE  Concept 


The  DBASE  module  is  comprised  schedule  and  exercise  data 
necessary  to  create  a  weekly  schedule  and  generate  required 
reports.  The  prototype  system  designed  by  this  study  w  1  1 
perform  the  first  three  functions,  and  in  doing  so  will  also 
make  available  all  data  necessary  for  accomplishment  of  the 
fourth. 

In  essence,  two  distinct  but  interrelated  applications 
will  be  created.  The  first  application  will  perform  those 
functions  of  the  Scheduler  related  to  the  gathering  and 
input  of  data  into  a  weekly  facilities  and  personnel  employ¬ 
ment  schedule.  The  final  product  of  this  application  will  be 
a  printed  schedule  of  weekly  activities.  The  second  applica¬ 
tion  will  provide  the  means  for  the  Program  Engineers  and 
Operations  Analysts  to  effect  the  collection  and  storage  of 
data  pertaining  to  the  exercises  conducted  on  the  ranges. 
Although  no  printed  reports  will  be  produced  by  the  proto¬ 
type  system,  all  data  required  for  those  reports  will  be 
stored  in  the  database. 

D.  METHODOLOGY 

Systems  analysis  is  basically  a  three  phase  process  de¬ 
signed  cO  gather  and  analyze  facts  pertaining  to  the  exis¬ 
ting  system.,  with  the  ultimate  goal  of  improving  that  system 
thr,p_igh  better  procc  cures  and  techniques. 

Du’^ing  the  study  phase,  information  is  gathered  rela¬ 
tive  to  the  capabilities  and  deficiencies  of  the  present 
system.  Specific  objectives  critical  in  developing  an  under¬ 
standing  of  the  system  are: 

•  Identify  all  knowledge  workers  who  use  or  are  affected 
by  the  current  system. 

•  Identify  the  purpose,  goals,  objectives  and  policies 
of  the  current  information  system,  and  analyze  the 
extent  to  which  the  mission  is  being  achieved. 
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•  Identi  /  the  in  f  orma  t ion  system  functions  provided  by 
the-  current  system  and  analyze  the  extent  to  which 
these  functions  support  the  l.nowledgt  workers  and  the 
mission  . 

•  Separate  the  current  information  system  into  its 
components  ar d  analyze  how  these  components  interact 
to  provide  tie  current  information  resources. 

[ Re  f .  2 : pg .  182 ] 


The  second  phase  of  systems  analysis  is  that  of  re¬ 
quirements  definition.  The  two  primary  goals  of  this  stage 
are  : 


•  Identification  of  the  objects  the  user  needs  to  track 
and  hpfinition  of  their  structure. 

•  De term  1 na 1 1 on  of  the  functional  components  of  each 
application  that  will  use  the  database.  [Ref.  3 : pg . 
89]  . 

Use’^  requirements  will  be  discussed  in  Chapter  II. 

Tne  third,  and  final  phase  of  systems  analysis  is  the 
design  phase,  which  consists  of  both  logical  design  (covered 
in  Chapter  III)  ^  \d  the  implementation  of  the  system  (dis¬ 
cussed  in  Chapter  IV). 

E.  FEASIBILITY 
1  .  'ost 

The  imp  i  emen  ta  ..  ion  of  the  prototype  system^  de¬ 
signed  by  this  study  will  require  a  minimum  of  add'tional 
funds.  Equipment  needed  for  the  system  is  presently  on  hand, 
and  the  time  and  e'^'fort  required  to  train  system  operators 
IS  expected  to  be  negligible.  The  limited  training  require¬ 
ments  are  primarily  due  to  the  users'  existing  knowledge  of 
tha  Oracle  database  s/stem,  the  Users'  Manual  and  the  de- 
signed-in  simplicity  of  the  user  interface. 

2.  Technical 

The  on  1 N,  tecfmical  limitations  imposed  by  the 
prcta'.ypfi  system!  are  those  associated  with  the  selection  of 
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Professional  ORACLE  as  the  designated  database  management 
system  to  be  employed.  The  system  requirements  for  use  of 
ORACLE  consist  of: 

•  Compaq  386,  IBM  PC/AT,  Personal  System/2  Models  50,  60 
and  80,  or  100'/.  compatibles. 

•  DOS  3.1  or  later  version,  or  OS/2. 

•  Up  to  6MB  of  local  hard  disk  to  accomodate  all  soft¬ 
ware  components  and  demonstration  databases. 

•  640  KB  of  regular  RAM  plus  896  KB  of  extended  RAM. 

[ Ref .  4 : pg .  10 ] . 

The  design,  development,  documentation  and  testing 
of  the  prototype  system  was  done  on  IBM-compatible  AT  machi¬ 
nes;  implementation  and  further  testing  will  be  done  at 
FACSFAC  on  an  IBM  Model  80.  All  system  requirements  listed 
above  are  currently  available  at  FACSFAC,  along  with  a 
technical  support  engineer  who  is  intimately  familiar  with 
the  ORACLE  database  management  system. 

3.  Schedule 

The  prototype  system  for  the  DBASE  component  of 
SCRAMBASE  is  being  developed  concurrently  with,  yet  indepen- 
ently  of,  the  other  two  components.  The  latter  impose  no  re¬ 
strictions  on  DBASE  development,  nor  do  they  more  than 
assoc  1  a 1 1 ve 1 y  depend  on  its  development.  In  that  the  SCRAM- 
NET  plan  is  a  long-term  process,  it  also  imposes  no  schedu¬ 
ling  constraints  on  the  development  of  this  system.  Thus, 
from  the  schedule  standpoint,  feasibility  is  assumed. 
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USER  REQUIREMENTS 


II  . 

The  determination  of  user  needs,  in  terms  of  both  data 
and  functional  requirements,  is  the  second  step  of  systems 
analysis.  First,  in  order  to  understand  better  the  needs  of 
the  FACSFAC  organization,  the  study  phase  examines  its 
current  method  of  data  collection  and  storage. 

A.  PRESENT  SYSTEM 

The  present  system  used  by  FACSFAC  was  seen  as  being 
two  separate,  but  interacting  applications.  Figures  2.1  and 
2.2  graphically  portray  the  two  applications.  In  those 
diagrams,  a  rectangle  represents  a  source/sink,  an  oval 
represents  a  function  being  performed,  an  arrow  shows  the 
flow  of  data  and  information,  and  the  two  parallel  lines 
represent  a  data  bank  or  database. 

The  first  application  consists  of  those  functions 
necessary  for  gathering  and  input  of  various  data  in  order 
to  create  weekly  and  monthly  schedules  of  activities  for 
FACSFAC  facilities  and  personnel  and  DVNACORP  personnel.  The 
scheduler  receives  the  Quarterly  Employment  Schedule  from 
the  Naval  Undersea  Warfare  Engineering  Station  (NUWES) 
containing  the  training  needs  of  the  various  client  com¬ 
munities.  He  then  creates  a  monthly  planner  for  internal  use 
only,  and  uses  it  as  a  guide  for  developing  the  upcoming 
weekly  schedules.  Using  the  monthly  planner  and  asset  avail¬ 
abilities  from  NUWES,  the  client  users  and  the  supporting 
commands,  the  scheduler  generates  individual  exercise  events 
linking  FACSFAC  facilities  with  the  training  requirements  of 
the  clients.  FACSFAC  and  DYNACORP  personnel  are  then  matched 
with  the  exercise  events,  and  a  weekly  activities  schedule 
IS  thus  created  and  distributed.  Modifications  to  that 
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schedule  are  made  as  needed,  based  upon  inputs  from  NUWES, 
the  supporting  commands  and  clients. 


Figure  2.1  Current  Scheduling  System. 


The  second  application  consists  of  those  activities 
involved  in  collecting  post-exercise  information  for  the 
purpose  of  generating  required  reports  and  performing  ana¬ 
lyses  on  the  tactical  employment  data  gathered  during  the 
exercise.  In  this  application,  the  Program  Engineer  accumu¬ 
lates  tactical  data  during  the  exercise  from  both  personal 
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Figure  3.2  Current  Exercise  Results  Function. 

observation  and  inputs  from  the  Operations  Analyst,  Opera¬ 
tions  Controller  and  range  Safety  Officer.  These  data  are 
combined  with  data  obtained  from  the  client  users  during  the 
event  debrief  to  create  an  Exercise  Summary  document  which 
is  then  filed,  an  Attack/Exercise  Performance  Evaluation, 
and  a  MK46  Rapid  Feedback  Firing  Report,  if  applicable.  The 
Operations  Analyst  periodically  accesses  the  filed  documents 
in  order  to  produce  assorted  other  required  reports. 
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B.  REQUIREMENTS  DEFINITION 

The  second  stage  of  systems  analysis  is  that  of  re¬ 
quirements  definition,  wherein  the  determination  is  made  as 
to  exactly  what  the  new  system  must  do.  These  requirements 
consist  of  both  the  data  objects  which  must  be  captured  by 
the  system,  and  the  functions  that  the  new  system  must  be 
able  to  perform. 

1.  Data  Requirements 

System  data  requirements  were  determined  through  a 
series  of  interviews  conducted  with  the  prospective  system 
users  and  management  at  FACSFAC.  These  requirements  were 
then  translated  into  objects,  diagrams  and  spec ifications. 
Appendix  A  contains  object  diagrams.  Appendix  B  the  object 
specifications,  and  Appendix  C  the  definition  and  other  data 
of  each  domain. 

In  keeping  with  the  scope  of  the  project  as  de¬ 
scribed  in  Chapter  I,  the  database  system  for  FASCFAC  is 
envisioned  as  being  two  primary  applications:  schedule  and 
exercise  results.  The  schedule  application  will  store  all 
data  relevant  to  the  schedule,  but  will  not  perform  the 
actual  scheduling.  The  second  application,  referred  to  as 
the  results  application,  will  store  all  the  results  of  an 
particular  event.  In  terms  of  a  time  line,  scheduling  is 
concerned  with  an  event  before  it  occurs,  and  exercise 
results  is  concerned  with  post-event  analysis. 

a.  Schedule  Application  Objects 

The  schedule  application  stores  the  schedule 
in  an  easily  updatable  form  to  accommodate  the  many  changes 
that  occur  during  the  scheduling  process.  This  is  accom¬ 
plished  by  breaking  the  data  down  into  the  five  entities 
with  which  the  scheduler  normally  works:  the  exercise  event 
itself,  the  brief,  the  users,  the  weapon  and  the  target. 
These  five  entities  are  represented  by  corresponding  objects 
of  the  same  names.  Of  these  five  objects,  the  main  one  is 


10 


the  EXERCISE  object,  since  it  contains,  directly  or  indi¬ 
rectly,  all  the  other  objects.  This  is  consistent  with  the 
view  of  the  FACSFAC  personnel  who,  in  most  instances,  view 
the  exercise  as  one  entity,  but  at  other  times  see  each 
object  as  separate  entities. 

The  exercise  entity  is  represented  by  the 
EXERCISE  Object  which  uniquely  identifies  an  instance  of  an 
exercise  (referred  to  as  an  event)  by  the  Exercise  Type  and 
Event  Number.  Normally,  the  scheduler  concatenates  these  two 
numbers  to  form  one  event  identifier.  The  Exercise  Type 
indicates  the  specific  type  of  exercise  to  be  run,  such  as  a 
submarine  torpedo  exercise  or  an  S-3  electronic  warfare 
exercise.  This  data  is  important  to  the  database  because 
each  exercise  has  unique  information  storage  requirements. 
For  example,  electronic  warfare  exercises  do  not  require 
weapons  or  targets,  thus  these  objects  need  not  be  recorded 
as  part  of  the  EXERCISE  object.  The  Event  Number  uniquely 
Identifies  an  individual  event  within  each  exercise  type. 
This  number  is  a  sequential  number  for  each  exercise  type 
conducted  during  a  given  year.  The  EXERCISE  object  also 
contains  gene'^al  scheduling  information  concerning  the 
event,  such  as  date  and  times,  personnel,  and  message  re¬ 
quirements.  Required  exercise  support,  in  the  form  of  target 
and  weapon  recovery  vehicles,  is  also  identified  in  this 
object. 

The  BRIEF  Object  consists  of  information 
relevant  to  each  briefing.  Normally,  there  is  a  minimum  of 
two  briefs  associated  with  each  event;  a  pre-event  brief  and 
a  post-event  brief.  The  BRIEF  object  is  used  to  create  a 
Weekly  Briefings  Report  to  ensure  not  only  that  briefer 
knows  when  and  where  his  briefings  are  to  be  held,  but  also 
to  allow  others  to  schedule  the  briefing  room  on  an  "as- 
available"  basis.  Each  brief  is  identified  by  its  title. 


The  TARGET  Object  contains  information  about 
the  target(s)  to  be  used  during  a  given  exercise.  Creating 
this  separate  object  ensures  that  the  correct  target  parame¬ 
ters  are  being  used  for  each  exercise  event.  The  TARGET 
object  also  contains  the  information  needed  to  schedule  the 
target  launch  vehicle(s).  FACSFAC  personnel  view  this  as 
being  a  separate  object,  mainly  to  depict  how  the  infor¬ 
mation  about  the  targets  is  received.  When  the  schedule  is 
finalized,  it  is  sent  to  the  commands  responsible  for  target 
support,  and  targets  are  provided  to  match  the  scheduled 
need.  The  number  and  type  of  targets  needed  for  an  event 
vary  with  the  type  of  exercise  being  conducted  and  the 
number  of  participants  in  a  particular  event.  Thus,  the 
TARGET  object  can  be  multi-valued  within  the  EXERCISE  ob¬ 
ject.  The  TARGET  object  is  identified  by  Exercise  Type, 
Event  Number  and  Target  Designation. 

The  USERS  Object  contains  those  attributes 
describing  the  client  users  of  the  range.  FACSFAC  considers 
this  as  being  an  object  because  each  client  ship  or  squadron 
is  a  unique  entity.  In  this  application,  at  least  one  client 
command  is  associated  with  an  exercise  event  and  the  USERS 
object  describes  those  command  characteristics  relevant  to 
an  event.  Each  exercise  event  may  have  multiple  users,  to 
include  the  target  itself  if  it  is  a  ship  or  subma'^ine.  For 
aircraft  squad'^ons  the  USER  object  also  includes  the  number 
of  aircraft  from  that  command  participating  in  the  exercise 
event.  The  USERS  object  also  contains  the  multi-valued 
WEAPON  object.  It  is  identified  by  Exercise  Type,  Event 
Number  and  Command  Name. 

The  WEAPON  Object  is  very  similar  to  the 
TARGET  object,  in  that  it  serves  the  function  for  weapons  as 
the  TARGET  object  does  for  targets.  As  the  TARGET  object  is 
multi-valued  within  an  EXERCISE  object,  the  WEAPON  object  is 
multi-valupd  within  a  USERS  object,  with  the  normal  number 
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of  weapons  being  two  for  each  participant  in  an  event.  The 
WEAPON  object  is  identified  by  Weapon  Type  and  Command  Name. 
b.  Results  Application  Objects 

The  RESULTS  Object  is  the  main  object  of  the 
exercise  results  application.  It  has  the  same  identifier  as 
the  EXERCISE  object  with  which  it  is  associated.  A  great 
deal  of  the  information  in  the  results  application  is  trans¬ 
ferred  from  the  scheduling  application  as  default  data.  In 
addition  to  other  attributes,  the  RESULTS  object  contains  a 
multi-valued  attribute,  'reason  cancelled' ,  which  records 
the  reason(s)  why  an  exercise  was  either  partially  or  en¬ 
tirely  cancelled,  and  the  range  utilization  hours  lost  for 
each  given  reason.  The  RESULTS  object  also  contains  all 
other  objects  that  are  part  of  the  Resu Its  application. 

The  PLATFORM  Object  stores  information  about 
the  individual  unit  that  conducted  an  attack.  The  attacking 
unit  can  be  either  a  ship,  an  aircraft  or  a  submarine. 
Additionally,  a  unit  may  conduct  multiple  attacks  on  a 
target  during  an  event.  The  PLATFORM  object  records  usage  of 
expendable  ordnance  (sonobuoys)  and  reasons  that  scheduled 
weapon  drops  were  not  made.  This  object  is  identified  by 
Exercise  Type,  Event  Number,  Command  Name  and  Side  Number. 

The  ATTACK  Object,  contained  within  the 
PLATFORM  object,  is  the  heart  of  the  results  application.  It 
records  all  information  associated  with  each  attack  instance 
occurring  for  a  given  platform  during  a  particular  event.  An 
instance  of  attack  can  be  real,  in  which  an  exercise  torpedo 
is  actually  expended,  or  simulated.  The  ATTACK  object  also 
records  how  well  the  platform  performed  in  carrying  out  its 
attack(s).  The  information  stored  can  be  used  later  to 
evaluate  the  tactical  proficiency  of  the  platform,  squadron 
and  community.  An  attack  is  uniquely  identified  by  a  time  of 
fire  and  the  associated  platform  conducting  the  attack.  Data 
recorded  in  each  attack  instance  includes  the  accuracy  of 
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the  platforms  solution  at  the  time  of  the  attack,  the 
tactical  employment  of  the  platform  at  the  time  of  attack, 
and  whether  or  not  the  attack  was  successful.  The  ATTACK 
object  also  contains  the  multi-valued  object  WEAPON  RESULTS. 

The  WEAPON  RESULTS  Object  contains  informa¬ 
tion  pertaining  to  weapon  performance  and  recovery,  and 
individual  instances  are  identified  by  the  type  (mk)  and 
serial  number  of  the  weapon.  The  one  WEAPON  RESULTS  attrib¬ 
ute  relevant  to  the  ATTACK  object  is  'torpedo  performance' . 
Should  an  exercise  torpedo  malfunction,  the  platform  con¬ 
ducting  the  attack  cannot  be  held  responsible  for  the  weapon 
missing  the  target.  Thus,  the  torpedo's  performance  must  be 
recorded  in  the  ATTACK  object.  The  WEAPON  RESULTS  object 
also  contains  the  LOST  object. 

The  TARGET  RESULTS  Object  records  data  about 
the  target  used  during  the  exercise  event  and  its  perfor¬ 
mance  during  the  course  of  the  exercise.  This  object  is 
identified  by  the  target  designatioh,  which  is  a  serial 
numoer  for  a  range  target,  or  a  ship  designation  or  hull 
number  if  the  target  was  an  actual  submarine  or  ship.  If  a 
ship  or  submarine  is  used  as  a  target  then  the  only  target 
inform, ation  that  applies  are  track  quality  and  sound  augmen¬ 
tation  information.  The  TARGET  RESULTS  object  records  the 
success  or  failure  of  target  recovery  operations,  and  also 
contains  the  LOST  object,  which  stores  data  abou  t  lost 
torpedoes  and  targets. 

The  LOST  Object,  contained  within  the  TARGET 
RESULTS  and  WEAPON  RESULTS  objects,  records  information 
pertaining  to  lost  torpedoes  and/or  targets.  It  is  consi¬ 
dered  separate  from  the  WEAPON  RESULTS  and  TARGET  RESULTS 
objects  because  its  occurrence  is  so  rare  (perhaps  three  or 
four  times  a  year).  Each  instance  is  identified  by  the 
weapon  type  (mk)  and  serial  number,  or  target  designation 
and  serial  number.  The  LOST  object  is  associated  with  a 
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thus  other  needed  information  for  that 


particular  event, 
object  can  be  obtained  from  ocher  objects  of  that  event. 

2.  Functional  Requirements 

The  objects  described  above  reflect  the  users' 
view  of  what  must  be  captured  in  the  new  system.  The  func¬ 
tional  requirements  specify  the  actual  database  application 
requirements  of  the  system,  and  are  portrayed  graphically  in 
the  data  flow  diagrams  (DFD)  in  Appendix  D. 
a.  Schedule  Application 

The  functional  requirements  of  the  schedule 
application  consist  of  creating  an  exercise  event  and  dele¬ 
ting  /mod  i  f  y  inq  an  exercise  event.  The  term  "exercise  event" 
as  used  here  means  both  the  Exercise  object  and  its  associa¬ 
ted  objects  (Brief,  User,  Weapon  and  Target).  The  creation 
and  mod i f ica t ion /de 1 e t ion  of  an  exercise  are  shown  DFD  (A) 
and  (B),  respectively.  In  creating  a  new  event,  the  schedu¬ 
ler  gathers  data  (objects)  from  the  Program  Manager,  the 
Program  Engineer,  NUWES  and  the  Supporting  Commands.  This 
information,  combined  with  the  monthly  planning  schedule 
stored  in  the  O-Base  database,  is  used  to  create  a  single, 
unique  exercise  event  (object).  The  scheduler  forwards 
exercise  events  for  an  entire  week,  in  the  form  of  a  tenta¬ 
tive  weekly  schedule,  to  the  Range  Manager  for  review  and 
approval.  Any  modifications  to  an  event  by  the  Range  Manager 
are  sent  back  to  the  scheduler  for  change  and  are  re-sub- 
mitted  for  approval.  The  approved  weekly  schedule  is 
returned  to  the  scheduler  who  distributes  it  and  issues  a 
Weekly  Briefings  Report,  depicting  all  scheduled  briefs  for 
the  week,  including  times,  locations  and  briefing  officers. 

In  the  second  part  of  the  schedule  applica¬ 
tion,  the  scheduler  receives  recommended  changes  to  and 
deletions  from  events  in  the  weekly  schedule.  These 
recommendations  come  from  the  Program  Manager,  the  Program 
Engineer,  the  client  User  Commands,  NUWES  and  the  Supporting 
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Commands  and  are  forwarded  to  the  Range  Manager  for  appro¬ 
val.  Upon  receipt  of  approval,  the  scheduler  issues  an 
updated  weekly  schedule  and  a  modified  Weekly  Briefings 
report  reflecting  the  changes. 

b.  Exercise  Results  Application 

The  third  DFD  portrays  the  functional  re¬ 
quirements  of  the  Exercise  Results  application,  which  con¬ 
sist  of  those  processes  necessary  to  gather  and  store  exer¬ 
cise  results  data.  This  includes  not  only  the  Result  object, 
but  also  the  Platform,  Attack,  Weapon  Result,  Target  Result 
and  Lost  objects.  These  data  can  then  be  used  for  user 
performance  evaluations  and  for  the  creation  of  periodic  and 
aperiodic  reports.  Data  contained  in  the  Exercise  event  and 
stored  in  the  Q-Base  database  are  retrieved  by  a  clerk  and 
combined  with  post-exercise  data  from  the  0-Base  database 
(Results  Object)  to  create  an  Exercise  Summary,  which  is 
passed  to  the  Program  Engineer  (PE)  for  review  and  approval. 
Also  passed  to  the  PE  is  a  list  of  scheduled  exercise  events 
in  the  database  which  have  no  corresponding  Results  object. 
The  PE  files  the  Summary  and  takes  action  to  ensure  that  all 
exercise  events  have  associated  Results  in  the  0-Base  data¬ 
base.  The  PE  also  retrieves  P 1  a t f orm/ A t tac k  data  from  the 
database  in  order  to  produce  a  Mk-46  Rapid  Feedback  Firing 
Report  for  distribution  to  the  user  command  following  the 
exercise.  The  Operations  Analyst  and  Program  Manager 
retrieve  Results  and  Platform  data  from  the  database  in 
order  to  create  periodic  reports  for  the  Fleet  Commanders, 
User  Commands  and  for  internal  FACSFAC  distribution.  Lastly, 
the  communicator,  who  may  also  be  the  PE,  creates  and 
distributes  the  Mk-46  Quarterly  Firing  Report  to  Naval  Sea 
Systems  Command  . 

The  Update,  Display  and  Control  Mechanisms 
required  for  the  system  are  as  shown  in  Appendix  E. 
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III.  SYSTEM  DESIGN 


The  third  phase  of  the  systems  analysis  process  is  the 
design  of  the  system.  It  is  during  this  phase  that  the 
foundation  of  the  database  structure  is  built.  The  design 
step  actually  consists  of  two  phases:  the  logical  design 

phase  and  the  application  design  phase.  The  goal  of  logical 
database  design  is  to 

represent  objects  in  the  database  using  relations  that 
(1)  provide  the  data  needed  to  construct  user  objects 
and  (2)  are  robust  enough  to  allow  rows  to  be  insertea, 
deleted  and  modified  without  resulting  in  inconsisten¬ 
cies  or  errors  in  the  stored  data.  [Ref.  3 : pg .  133] 

‘Jnder  logical  database  design,  items  to  be  discussed 
include  the  concepts  of  relations,  primary  and  foreign  keys, 
-relationships,  relationship  constraints  and  normalization. 
In  the  application  design  phase,  the  applications  and  their 
scope  Will  be  addressed,  along  with  control  mechanisms  and  a 
description  o'f  the  menu  hierarchy. 

A.  LOGICAL  DATABASE  DESIGN 

In  this  step,  each  object  developed  in  the  user's 
requirements  phase  is  translated  into  one  or  more  two-dimen¬ 
sional  tables,  called  relations.  Each  row  in  a  relation  is 
called  a  tuple,  and  corresponds  to  a  record.  Each  column  is 
an  attribute,  and  corresponds  to  a  field.  The  relations 
thus  created  are  depicted  in  Appendix  F.  A  simple  object, 
such  as  Brief  or  Target,  which  contains  only  s ing 1 e-va 1 ued , 
non-object  properties,  is  represented  by  a  single  relation. 
A  composite  object,  on  the  other  hand,  is  one  containing  one 
or  more  non-object  multivalued  properties,  and  requires  more 
than  one  relation  for  their  representation.  For  example,  the 
Result  object  (Appendix  A)  contains  several  non-object, 
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multivalued  prope'^ties  which  are  translated  into  the  Support 
and  Cancel  relations  given  in  Appendix  F.  A  compound  object 
contains  at  least  one  object  property,  requiring  translation 
of  that  object  into  several  relations,  each  of  which  could 
stand  on  its  own.  For  example,  the  Exercise  object  of  Appen¬ 
dix  A  contains  the  object  properties  Brief,  User  and  Target, 
each  of  which  forming  its  own  relation  in  Appendix  F. 

1 .  Relation  Keys 

Each  relation  has  a  set  of  attributes,  called  the 
key,  wt-’ich  uniquely  identifies  a  tuple.  These  keys  are 
underlined.  In  the  Exercise  relation  the  key  consists  of 
Exercise  Type  ( E  xer  .  and  Event  Number  ( Even  t )  .  In  all  of  the 
other  relations  of  the  Schedule  Application,  except  for 
B'^ief,  Exercise  Type  and  Event  Number  appear  as  part  of  the 
key,  whe-'e  they  represent  a  foreign  key  (the  key  of  another 
neiation),  as  indicated  by  the  asterisk.  In  the  Brief  rela¬ 
tion,  Bnief  1 1 1  e  (Title)  and  Brief  Time  (  T  i  me  )  are  the  key 
attributes,  Out  the  relation  contains  Exer  and  Event  as  a 
foreigr  key. 

In  the  Exercise  Results  Application,  Exer  and 
Event  are  also  common  m  most  of  the  keys,  the  exceptions 
being  the  Attack  relation  and  those  multi-valued  objects  and 
attributes  associated  with  it.  Exer  and  Event  are,  however, 
present  m  the  Attack  relation  as  a  foreign  key,  as  are 
Command  and  Sideno  (comprising  the  Platform  key).  Thus,  an 
attac-  cari  be  associated  with  both  an  exercise  event  and  a 
specific  platform.  In  a  similar  manner,  the  Lost  relation, 
with  i s  multiplicity  of  foreign  keys,  can  be  associated 
directly  with  an  exercise,  an  attack,  a  weapon  and/or  a 
target . 

2.  Relationships 

A  binary  relationship  is  one  that  involves  only 
two  recorb  types.  Whereas  an  object  was  converted  on  a  one- 
to-one  basis  into  a  relation  (record  type),  the 
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r e i a t 1 ons h 1 ps  between  those  record  types  are  not  necessarily 
limited  to  one-to-one.  Tn  fact,  in  this  database  the  majori¬ 
ty  of  the  relationships  are  one-to-many.  Referring  again  to 
the  relation  d  agrams  of  Appendix  F,  a  given  exercise  may 
have  multiple  users  associated  with  it,  as  indicated  by  the 
"fork"  on  the  User  end  of  the  connecting  line.  Similarly,  an 
exercise  can  have  many  briefs  and  targets  and  a  user  may 
have  more  than  one  weapon. 

□ne-to-one  relationships  exist  between  the  Attack 
and  WeaponR  record  types,  in  that  any  attack  can  only  have  a 
single  weapon  result  associated  with  it.  Correspondingly,  a 
weapon  can  only  have  one  attack  associated  with  it  during  a 
given  exercise.  The  Lost  relation  similarly  shares  one-to- 
one  relationships  with  WeaponR  and  TargetR  record  types. 

F  simplified  relationship  diagram  for  the  schedule 
application  can  pe  seen  in  Figure  3.1  below,  and  one  for  the 
exercise  results  application  in  Figure  3.2. 


Figure  3.1  Schedule  Application  Relationships 


Figure  3,2  Results  Application  Relationships 
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3.  Relationship  Constraints 

Another  notation  used  in  Figures  3.1  and  3.2  and 
in  Appendix  F  is  one  to  indicate  a  mandatory  or  optional 
relationship  between  two  record  types.  A  circle  at  the  end 
of  a  line  indicates  an  optional  association.  For  example,  an 
exercise  may  have  a  target  (or  more  than  one)  associated 
with  it,  and  a  platform  may  conduct  one  or  more  attack.  A 
bar  at  the  end  of  the  connector  indicates  a  mandatory  rela¬ 
tionship.  For  example,  a  weapon  results  relation  ( WEAPONR ) 
must  have  an  attack  associated  with  it. 


20 


The  exercise  and  brief  relationships  are  optional 
in  each  direction.  This  is  because  an  exercise  may  have  only 
one  brief  associated  with  it  (rather  than  the  normal  two), 
or,  in  the  case  of  a  range  maintenance  period  (designated  as 
an  exercise  for  scheduling  purposes),  there  may  be  no  sched¬ 
uled  brief  at  all.  Additionally,  a  brief  may  be  scheduled 
that  does  not  relate  to  a  specific  exercise. 

4.  Normalization 

The  relations  created  in  this  project  are  all  in 
at  least  third  normal  form  ( 3NF ) .  A  relation  can  be  con¬ 
sidered  as  being  in  3NF  if  (1)  all  non-key  attributes  are 
dependent  on  all  of  the  key,  and  (2)  if  it  contains  no 
transitive  dependencies.  For  example,  in  the  case  of  the 
Target  relation,  the  Geometry,  Acoustics,  Tpinger  and 
Lnchveh  attributes  are  each  dependent  on  Exer .  Even t  and 
T  q  tdes ig  and  only  on  those  attributes. 

B.  APPLICATION  DESIGN 

Data  flow  diagrams  (DFD)  were  developed  during  the  user 
requirements  phase  in  order  to  identify  the  functional  needs 
of  the  or gan 1 H a t ion .  In  the  application  design  step,  these 
DFDs  are  transposed  into  a  functional  hierarchy  structure, 
as  shown  in  Appendix  G.  Each  block  or  module  (14=  4  4pe-=ific 
abject  or  function,  and  each  module  contains  sub-modules, 
selection  of  which  will  result  in  a  specific  task  being  per¬ 
formed.  These  hierarchy  structures  also  serve  to  delineate 
the  applications  and  the  scope  of  the  project,  which  have 
been  well-defined  in  previous  chapters  and  will  not  be 
repeated  here. 
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Control  Mechanisms 


1 . 

After  determining  the  number  and  scope  of  the 
applications,  the  next  step  in  application  design  is  to 
devise  the  control  mechanisms  associated  with  the  applica¬ 
tions.  A  menu-driven  application  is  considered  to  be  the 
most  appropriate  control  mechanism  for  this  project,  due 
primarily  to  its  simplicity  of  design  and  ease  of  use. 
Minimum  time  will  be  necessary  to  train  the  operators  in  the 
use  of  the  menus,  because  they  are  self-explanatory.  Addi¬ 
tionally,  a  menu  driven  application  is  far  easier  to  under¬ 
stand  than  one  which  is  command-driven. 

2.  Menu  Hierarchy  Descriptions 

The  final  stage  of  application  design  consists  of 
converting  the  entity-relationship  structures  into  a  series 
of  menus.  A  set  of  menus  is  perhaps  the  easiest  method  of 
providing  user  interface  with  the  application  functions. 
Additionally,  they  simplify  user  learning,  understanding  and 
utilization  of  the  system.  Examples  of  the  various  menus 
corresponding  to  the  hierarchic  structures  are  illustrated 
in  the  figures  and  described  below, 
a.  Main  Menu 

The  main  0-Base  menu  shown  in  Figure  3.3 
allows  the  user  to  select  which  a.^plication  to  enter,  or 
permits  him  to  exit  back  to  the  operating  system.  As  men¬ 
tioned  above,  permission  to  enter  a  selected  function  will 
be  governed  by  the  password  of  the  user. 
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Figure  3.3  System  Main  Menu 

b.  Schedule  Application  Menu 

The  Schedule  Application  menu  (Figure  3.4) 
provides  the  user  with  the  options  of  selecting  an  item 
within  the  schedule  application  for  update,  or  performing 
one  of  the  two  print  functions  associated  with  the  applica¬ 
tion.  The  user  also  has  the  option  to  exit  to  the  main  menu. 
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SCHEDULE  APPLICATION  MENU 


Event  . 

1 

Brief  . 

2 

User  . 

3 

Weapon  . 

4 

Target  . 

6 

Print  Schedule  .  . 

6 

Print  Brief  Rpt  .  . 

7 

EXIT  TO  MAIN  MENU  ■ 

6 

Enter  Desired  Selection: 

— 

Figure  3.4  Schedule  Application  Menu 

b.  Schedule  Functions  Menu 

Following  selection  of  an  object  to  update 
from  the  previous  menu,  the  user  is  presented  with  a  menu 
displaying  the  various  functions  available  (Figure  3.5). 

When  creating  (adding)  an  event,  the  user  enters  all  known 
data  associated  with  that  event,  including  brief,  user, 
weapon  and  target  information.  Additionally,  a  brief  can  be 
added,  modified  or  deleted  individually.  Modification  of 
user,  weapon  and  target  data  associated  with  an  existing 
exercise  event  is  accomplished  through  modifying  the  event 
itself.  Deletion  of  an  event  deletes  all  user,  weapon, 
target  and  brief  information  associated  with  that  event. 

The  user  also  has  the  option  to  execute  user-defined  queries 
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on  each  of  the  exercise  objects.  Lastly,  the  user  can  either 


exit  to  the  previous  menu  or  exit  to  the  main  menu. 


SCHEDULE  FUNCTION  MENU 


Add  .  1 

Modify .  2 

Delete .  3 

Query  .  4 

EXIT  TO  SCHED  MENU  .  .  6 

EXIT  TO  MAIN  MENU  ...  6 


Enter  Desired  Selection 


Figure  3.5  Schedule  Functions  Nenu 


c.  Exercise  Results  Application  Menu 

This  menu  (Figure  3.6)  permits  the  user  to 
enter  into  the  second  application  of  the  system  —  the 
Exercise  Results  application.  When  a  selection  is  made  of 
one  of  the  objects  associated  with  the  results  application, 
the  user  is  presented  with  a  Results  Functions  menu  similar 
to  the  one  for  the  Schedule  application  (see  Figure  3.5).  It 
is  through  the  functions  menu  that  the  update  of  the  selec¬ 
ted  object  IS  performed.  Additionally,  the  user  has  the 
oction  of  selecting  a  Report  Generator  function  from  this 
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menu.  Although  beyond  the 
enhancements  to  the  system 
through  this  function.  The 
main  menu. 


scope  of  this  project, 
could  permit  automated 
user  also  may  exit  back 


future 
reports 
to  the 


RESULTS  /PLICATION  MENU 

Exercise  Result  ....  i 

Platform  .  2 

Attack  .  3 

Weapon  .  4 

Target  .  5 

Report  Generator  .  .  6 

EXIT  TO  MAIN  MENU  ...  7 


Enter  DeelrecJ  Seleotlor\  ... 


Figure  3.6  Results  Application  Menu 


If  the  user  desires  to  create  a  new  exercise 
result,  he  selects  "Exercise  Result"  from  the  Results  Ap¬ 
plication  Menu,  followed  by  "Add"  from  the  Results  Functions 
Menu.  He  is  then  cycled  through  all  relevant  objects  as¬ 
sociated  with  the  new  exercise  result.  Individual  objects, 
such  as  Attack,  are  added  in  the  same  manner.  Deletion  of  a 
Platform  requires  prior  deletion  of  any  Attack  and  Weapon 
associated  with  that  platform.  Deletion  of  a  Result  will 
cause  the  deletion  of  all  objects  assoc iated  with  it.  Any 
other  object  may  be  deleted  individually. 
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IV.  SYSTEM  IMPLEMENTATION 


A.  INTRODUCTION 

The  second  step  in  the  design  phase,  and  the  final  step 
in  the  systems  analysis  cycle,  is  implementation.  The  main 
task  of  of  implementation  is  to  construct  a  system  according 
to  the  design.  In  this  step,  the  relations,  rows  and  at¬ 
tributes  of  the  design  phase  are  translated  into  DBMS-speci¬ 
fic  tables,  records  and  fields. 

Based  on  application  design,  the  application  develop¬ 
ment  tools  of  Oracle  are  used  to  construct  the  forms,  re¬ 
ports  and  menus  needed  in  the  system.  The  Oracle  DBMS  will 
be  addressed  after  a  discussion  of  table  and  screen 
generation . 

1.  Database  Tables 

Data  requirements  were  identified  during  the  user 
requirement  phase  and  were  presented  in  the  form  of  objects. 
During  the  logical  design  phase  of  the  last  chapter,  the 
objects  were  translated  into  corresponding  relations,  and 
relationships  between  the  relations  were  established.  In  the 
implementation  phase,  these  relations  are  translated  into 
DBMS-specific  (Oracle)  tables.  These  tables  are  the  essence 
of  data  storage  and  management  in  the  database  management 
system.  Each  table  consists  of  a  series  of  columns,  or 
fields,  which  equate  to  the  attributes  of  the  logical  rela¬ 
tions.  A  single  row  of  data  within  a  table  is  referred  to  as 
a  record . 

A  listing  of  all  tables  created  for  this  project 
is  found  in  Appendix  H.  The  first  section  of  the  appendix 
contains  those  tables  necessary  for  the  storage  and  display 
of  the  actual  data,  while  the  second  section  contains  the 
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look-up  tables  designed  to  assist  the  user  in  making  proper 
entries  in  various  fields. 

Appendix  I  presents  the  associations  between  the 
descriptive  names,  domain  names  and  actual  table  field  names 
for  each  object. 

2.  Screen  Designs 

The  second  task  of  the  user  requirements  phase  was 
the  identification  of  the  functional  requirements  of  the 
system.  The  task  was  accomplished  by  the  creation  of  a 
series  of  data  flow  diagrams  ( DFD ) .  The  logical  design  phase 
converted  the  DFDs  into  menus  that  allowed  the  user  to 
control  the  insertion,  modification  and  deletion  functions. 
During  the  implementation  phase,  the  menus  are  translated 
into  screens,  or  views,  which  provide  the  user  the  actual 
mechanisms  for  update  and  display  of  the  data.  The  screens 
are  the  materializations  of  the  objects,  containing  selected 
rows  and  columns  of  the  underlying  tables.  In  some  cases,  a 
single  screen  consists  of  two  or  more  joined  tables.  Because 
these  screens  are  not  stored  as  actual  physical  tables,  the 
views  can  be  termed  virtual  tables.  Appendix  J  contains  the 
various  screens  developed  for  the  two  applications.  The 
following  section  describes  the  DBMS  used  for  implementation 
of  this  proj  ec  t . 

B.  ORACLE  RELATIONAL  DATABASE  MANAGEMENT  SYSTEM  (RDBMS) 

Oracle  is  an  extremely  powerful.  Standard  Query  Lang¬ 
uage  (SQL)-based  relational  database  management  system.  The 
Oracle  corporation  has  added  non-standard  extensions  to  the 
SQL  language,  thus  term  their  product  "SQL#Plus".  Due  to  its 
utility  at  both  the  stand-alone  microcomputer  level  and  the 
network  level,  and  its  high  degree  of  portability,  it  was 
selected  by  FACSFAC  as  the  program  of  choice  for  their 
automated  database  system.  Hardware  and  system  requirements 
of  Oracle  were  presented  in  Chapter  I. 
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The  Oracle  products  include  a  variety  of  applications 
development  and  generation  tools,  providing 

complete  facilities  that  systems  designers  and  devel¬ 
opers  can  use  to  design,  develop  and  test  software 
products  whose  engine  is  the  Oracle  RDBMS.  [Ref.  5 :  pg . 

X  X  V  ] 

The  most  significant  tools  used  in  this  project  include 
SO  *Plus,  SQLfForms  and,  to  some  extent,  SQL*Report. 

1.  BQLtPlus 

The  developer  uses  the  SQL*Plus  query  language  to 
"create,  store,  modify,  retrieve,  print  and  manage  informa¬ 
tion  in  an  ORACLE  database"  [Ref.  6:pg.  ij.  Of  all  the  pro¬ 
grams  in  the  Oracle  system,  it  provides  the  most  direct 
access  to  the  data.  It  is  through  this  tool  that  the  tables 
were  created  and  the  data  was  inserted  into  the  tables. 

2.  SQLtForms 

This  tool  IS  used  by  both  the  system  developer  and 
the  system  operator.  The  developer  selects  the  rows  and 
columns  of  the  tables  for  display  in  screens  through  the  use 
of  the  SQL+Forms  program.  This  portion  of  the  program  is 
called  Design  forms.  After  the  form  has  been  generated,  the 
Run  form  procedure  permits  the  operator  to  work  with  the 
information  that  the  form  accesses.  Once  the  form  is  dis¬ 
played,  the  operator  is  able  to  perform  the  logical  menu 
functions  of  insertion,  deletion  and  modification  described 
in  the  previous  chapter, 

3.  SQLfReport 

Like  SQLKtForms,  this  program  also  has  two  utili¬ 
ties.  The  Report  Text  Formatter  ( RPF )  is  "a  general-purpose 
text  formatter  for  a  variety  of  word  processing  applications 
[Ref,  7 : pg .  9].  The  second  utility  is  the  Report 
Generator  (RPT),  which  enables  the  developer  to  extract 
speci'f'ic  data  from  the  database  and  include  it  in  a  report. 
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RPT  must  be  used  in  conjunction  with  some  type  of  text 
formatter,  such  as  RPF . 

A  far  more  powerful  report  generator,  SQL*Report- 
writer,  has  recently  been  marketed  by  the  Oracle  corpora¬ 
tion,  but  was  unavailable  for  this  project. 

C.  SOFTWARE  DOCUMENTATION 

1.  User  Manual 

The  user  manual  written  for  this  system  is  provi¬ 
ded  in  Appendix  K.  It  is  designed  for  a  user  familiar  with 
the  Oracle  RDBMS,  ha-ing  had,  as  a  minimum,  attended  an 
operator  training  course  or  read  an  operator  tutorial. 
Because  implementation  of  the  system  does  not  lend  itself  to 
a  menu  layout  in  the  Oracle  environment,  the  logical  menu 
functions  described  in  the  previous  chapter  are  performed 
through  the  activation  of  various  keyboard  keys.  The  func¬ 
tion  keys  and  special-purpose  keys  used  by  Oracle  and/or 
custom-designed  for  this  system  are  defined  in  the  user 
manual.  Also  included  in  the  manual  are  the  various  field 
constraints,  formats  and  masks  which  must  be  adhered  to 
while  creating  new  records. 

2.  Main  Program 

The  program  developed  for  this  project  is  written 
in  SQL,  a  powerful  fourth  generation  language  ( 4GL ) .  Because 
it  is  a  4GL ,  standard  program  descriptions  (structure 
charts,  etc.)  and  subroutines  are  not  applicable  to  the 
actual  design.  The  length  of  the  program  precludes  its 
incorporation  as  an  appendix. 

D.  REPORTS 

The  operator  has  the  option  to  print  two  standard, 
automated  reports  through  the  system:  1)  a  weekly  schedule 
of  activities,  and  2)  a  weekly  briefings  report.  These 
reports  were  created  using  SOLUtRepor t .  An  example  of  each  is 
presented  in  Appendix  L. 
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V. 


CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY  AND  CONCLUSIONS 

The  amount  and  complexity  of  the  operational  data 
collected  and  stored  by  the  Fleet  Area  Control  and  Surveil¬ 
lance  Facility  will  soon  overwhelm  the  manual  data  handling 
capabilities  of  the  command.  This  study  develops  a  relation¬ 
al  database  system  prototype  to  assist  the  organization  in 
those  critical  areas  of  its  activities.  One  of  the  main 
goals  is  to  increase  the  speed  and  accuracy  of  data  input, 
vhereby  enhancing  the  effectiveness  and  productivity  of  the 
unit.  Additionally,  a  powerful  database  query  function  and  a 
report  generation  capability  will  greatly  facilitate  user 
per f ormance . 

T ne  system  is  viewed  as  being  two  separate  but  interac¬ 
tive  applications.  The  scheduling  application  is  used  to 
input,  modify  and  delete  data  elements  associated  with 
creation  of  a  weekly  schedule  of  activities  and  a  weeily 
briefings  repo'^t.  The  results  application  is  designed  to 
allow  for  the  input,  modification  and  deletion  of  operation¬ 
al  data  gathered  during  fhe  execution  of  various  scheduled 
e  X  ere  1 ses . 

The  power  and  flexibility  of  ORACLE  made  it  the  program 
of  choice  by  FACSFAC  for  their  database  system.  Despite  its 
advantages,  ORACLE  is  difficult  to  apply  for  the  novice 
user,  thus  a  detailed  Users  Manual  is  provided  in  Appendix  K 
to  assist  the  operator.  The  prototype  system  was  designed 
With  the  goal  of  making  it  as  easy  as  possible  to  understand 
and  use,  however  a  certain  level  of  operator  knowledge  of 
ORACLE  IS  assumed.  The  Users  Manual  contains  a  section 
desc'^ibing  the  various  function  keys  and  their  applications 
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in  ORACLE,  as  well  as  the  special  purpose  keys  custom  de¬ 
signed  into  the  prototype  model  to  make  it  user-friendly. 

B.  RECOMMENDATIONS  AND  FUTURE  WORK 

Establishment  of  a  relational  database  allows  for 
future  expansion  and  capability  enhancements.  Using  data 
gathered  and  stored  in  the  results  application,  SQL*Report- 
writer  can  be  used  to  develop  an  automated  report  generation 
capability  for  the  operations  analyst.  Additionally,  the 
system  can  be  enhanced  through  the  incorporation  of  an 
automatic  scheduling  and  conflict  resolution  decision  sup¬ 
port  program.  Development  of  these  two  augmentations  to  the 
prototv'pe  will  serve  to  increase  command  efficiency  even 
further.  Finally,  the  ability  of  ORACLE  to  be  utilized  in  a 
network  environment  conforms  well  with  the  strategic  infor¬ 
mation  technology  goals  of  the  organization.  Development  of 
an  interactive  network  linking  the  three  databases  is  open 
for  further  study. 
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APPENDIX  A 


RELATIONAL  DATABASE  OBJECTS 


EXERCISE  OBJECT 


Exercise  T 


Event  Number 


Exercise  Description 
Scheduled  Start  Time 
Scheduled  Stop  Time 
NOCS  Start  Time 
MQCS  Stop  Time 
Operational  Area 
E  xc 1  us i ve 

Primary  Tgt  Recovery 
Secondary  Tgt  Recovery 
Primary  Wpn  Recovery 
Secondary  Wpn  Recovery 
Weapon  Haulback 
Tracking  Type 
Project  Engineer 
Operation  Controller 
Operation  Analyst 
Safety  Of  f icer 
Green  Message  Required 
Green  Message  Sent 
Submarine  Relaxation 
Message  Required 
Air  Space  Allocated 
Communications 
Commen  ts 
BRIEF  MV 
USERS  MV 
TARGET  MV 
RESULTS 


Location 

Briefer 

TARGET  OBJECT 

Exercise  Type 
Event  Number 
Target  Designation 
Target  Geometry 
Acoustics  Code 
Pinqer  Channel 
Launch  Vehicle 

WEAPON  OBJECT 

Weapon  Type 
Command  Name 
Number  Scheduled 
Pinger  Channel 

USERS  OBJECT 

Exercise  Type 
Event  Number 
Command  Name 
Number  of  Units 
EATS  Transponder 
Pinger  Channel 
WEAPON  MV 


RESULTS  OBJECT 


Exercise  Type 
Event  Number 
Exercise  Description 
Exercise  Attainment 
Comex 
F  inex 

Scheduled  Start  Time 

Scheduled  Stop  Time 

Oparea 

Visibility 

Sea  State 

Reason  Canceled  MV 
Hours  Lost  MV 

Cancel  Start  Time  MV 
Support  Platform  MV 
Support  Sidenumber  MV 
Support  Used  MV 

Classified  Comments 
Unclassified  Comments 

PLATFORM  MV 

TARGET  RESULTS  MV 


LOST  OBJECT 


Serial  Number 


T ime  Lost 
La  t i tude 
Long i tude 
I mp 1 osion 
Water  Depth 


ATTACK  OBJECT 


PLATFORM  OBJECT 


T ime  of  Fire 

*  Command  Name 

*  Side  Number 
Start  Op 

Actual  Target  Course 
Actual  Target  Bearing 
Actual  Target  Speed 
Actual  Target  Range 
Actual  Target  Depth 
Target  Maneuver  Time 
Target  Maneuver 
Course 

Target  Maneuver  Speed 
Target  Doppler 
Solution  Bearing 
Solution  Course 
Solution  Speed 
Solution  Range 
Heading  at  TQF 
Speed  at  TOF 
Mode 

Sonar  Setting 
Contact  Type 
Acquired 
Eval  of  Attack 
Search  Depth 
Commen  ts 
A 1 1 1 tude 
Delivery  Method 
Ph 

Bearing  to  Splash 
Point 

Range  to  Splash 
Poin  t 
Acquired 
Eval  of  Attack 
Search  Depth 
Commen  ts 

WEAPON  RESULTS 


*  Exercise  Type 

*  Event  Number 
Command  Name 
Side  Number 
Showed  Up 
Track  Quality 
Lof  ar 

Di  f  ar 
Dicas 
Vlad 


Weapon  Assigned  MV 
Number  of  Weapons  MV 
No  Drop  MV 

ATTACK  MV 
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APPENDIX  B 


OBJECT  DEFINITIONS 


EXERCISE  OBJECT 


Descriptive  Name _ Domain  Name 


Exercise  Type 

Exer 

Event  Number 

Even  t 

Exercise  Description 

Exdesc 

Schedule  Start  Time 

T ime-Schstar t 

Schedule  Stop  Time 

T ime-Schstop 

MOCS  Start  Time 

Time-MOCS  Start 

MOCS  Stop  Time 

Time-MOCS  Stop 

Operational  Area 

Oparea 

Exclusive  Use 

Primary  Target 

Exc 1 usi ve 

Recovery  Vehicle 
Secondary  Target 

Recovery-Pr i 

Recovery  Vehicle 
Primary  Weapon 

Recovery-Sec 

Recovery  Vehicle 
Secondary  Weapon 

Recovery-Pr i 

Recovery  Vehicle 
Weapon  Haulback 

Recovery-Sec 

Vehic  1  e 

Recovery-Hau 1 bac  k 

Tracking  Type 

Tracking  Type 

Project  Engineer 

Personnel -Pe 

Operation  Controller 

Personnel -Oc 

Operation  Analyst 

Personne 1 -Oa 

Safety  Officer 

Personnel -So 

Green  Required 

Message-Req 

Green  Sent 

Submarine  Relaxation 

Message-Sen  t 

Message 

Message-Sub 

Air  Space 

Air  Space 

Communications 

Communications 

Commen  ts 

Commen  ts 

BRIEF;  BRIEF  object; 

MV 

USERS:  USER  object;  MV 

TARGET:  TARGET  object; 

RESULTS;  RESULTS  object 

MV 
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BRIEF  OBJECT 


Descriptive  Name _ Domain  Name 


Brief  Title 

Brief  Title 

Brief  Time 

T ime-Brief 

Location 

Location 

Briefer 

Personnel -Brief 

USERS  OBJECT 

Descriptive  Name 

Domain  Name 

Exercise  Type 

Exer 

Event  Number 

Even  t 

Command  Name 

Command 

Number  of  Units 

Number-U 

EATS  Transponder 

T  ransponder 

Finger  Channel 

Pinger-U 

WEAPON:  WEAPON  object 

MV 

TARGET 

OBJECT 

Descriptive  Name 

Domain  Name 

Exercise  Type 

Exer 

Event  Number 

Even  t 

Target  Designation 

Target  Designa 

Geometry 

Geometry  Code 

Acoustics 

Acoustics 

Finger 

Pinger-T 

Launch  Vehicle 

Launc  h 

WEAPON 

OBJECT 

Descriptive  Name 

Domain  Name 

Mk 

Mk 

Command  Name 

Command 

Number  Scheduled 

Number — S 

Finger 

Finger — W 

3B 


RESULTS  OBJECT 


Descriptive  Name 

Domain  Name 

Exercise  Type 

Exer 

Event  Number 

Event 

Exercise  Description 

Exdesc 

Comex 

T ime-C 

Finex 

T ime-F 

Scheduled  Start  Time 

T ime-Schstart 

Scheduled  Stop  Time 

T ime-Schstop 

Operational  Area 

Oparea 

Visibi 1 ity 

Visible 

Sea  State 

Seastate 

Reason  Canceled 

MV 

Canceled 

Hours  Lost 

MV 

Hours 

Cancel  Start  Time 

MV 

Time-Cancel 

Support  Platform 

MV 

Command 

Support  Side  No. 

MV 

Sidenumber 

Support  Used 

MV 

Used 

Classified  Comments 

Commen  ts 

Unclassified  Comments 

Comments 

PLATFORM;  PLATFORM  object;  MV 

TARGET  RESULTS;  TARGET  RESULTS  object; 


PLATFORM  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 
Event  Number 
Command  Name 
Side  Sumber 
Showed  Up 
T rac  k  Qua  1 i ty 
Lot  ar 
Di  f  ar 
Dicass 
Vlad 

Weapon  Assigned  MV 

Number  of  Weapons 

Scheduled  MV 

No  Drop  MV 

ATTACK;  ATTACK  object; 


Exer 
Even  t 
Command 
Sidenumber 
Showed 

Track  Quality 
Sonobuoy  no. 
Sonobuoy  no. 
Sonobuoy  no. 
Sonobuoy  no. 
Mk 

Number — S 
Nodrop 
MV 


MV 
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TARGET  RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 
Event  Number 
Target  Designation 
Mod 

Serial  Number 
Target  Performance 
Geometry 
Launch  Time 
Target  Recovered 
Recovery  Vehicle 
Sound  Level 
Frequency 
Track  Quality 
LOST;  LOST  object 


Exer 
Even  t 

Target  Designation 
Mod 

Serial  Number 

Target  Performance 

Geometry  Code 

T ime-L 

Recovered 

Recovery 

Sound 

Frequency 

Track  Quality 


WEAPON  RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Time  of  Fire 

Mk 

Mod 

Serial  Number 
Torpedo  Performance 
Search  Time 
Weapon  Recovered 
Recovery  Vehicle 
Recovery  T ime 
Bring  Back  Vehicle 
Track  Quality 
LOST;  LOST  object 


TOF 

Mk 

Mod 

Serial  Number 
Torpper f 
Search-seconds 
Recovered 
Recovery 
Minutes-Recover 
Recovery 
Track  Quality 


LOST  OBJECT 


Descrii 


uomain 


Mk 

Mod 

Serial  Number 
Time  Lost 
Latitude 
Long i tude 
Implosion 
Water  Depth 


Mk 

Mod 

Serial  Number 
T ime-Lost 
Lat 
Long 

Depth- Imp 
Depth-Water 
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ATTACK  OBJECT 


Descriptive  Name 


Domain  Name 


Time  of  Fire 
Command  Name 
Start  Op 

Actual  Target  Course 
Actual  Target  Bearing 
Actual  Target  Speed 
Actual  Target  Range 
Actual  Target  Depth 
Target  Maneuver  Time 
Target  Maneuver 
Course 

Target  Maneuver 
Speed 

Target  Doppler 
Solution  Bearing 
Solution  Course 
Solution  Speed 
Solution  Range 
Heading  at  TOF 
Speed  at  TOF 
A1 ti tude 
Mode 

Sonar  Setting 
Contact  Type 
Delivery  Method 
Bearing  to  Splash 
Point 

Range  to  Splash 
Point 
Acquired 
Eval  of  Attack 
Search  Depth 
Comments  MV 

Line  Number  MV 

WEAPON  RESULTS;  WEAPON 


T ime-Tof 
Command 

T ime-S tart- time 

Compass-Tc 

Compass-Tb 

Kts-Ts 

Range-T 

Depth-T 

Minutes-Maneuver 

Compass-Tm 

Kts-Tm 

Dopp 1 er 

Compass-Sb 

Compass-Sc 

Kts-S 

Range-S 

Compass-Heading 

Speed 

Height 

Modecode 

Sonar 

Contact  Code 
Delivery  Code 

Compass-Splashpt 

Range-Splashpt 
Acquired 
Eval 
Depth-S 
Comments 
Linenumber 
RESULTS  object; 
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APPENDIX  C 


DOMAIN  DEFINITIONS 


Acoustics  Code: 
char  ( 1 ) 
range:  Y,  N 

Indicates  whether  or  not  the  target  acoustics  are  those 
required . 

Acqu i red : 

number  (1),  integer 
range:  0-9 

The  number  of  times  that  the  torpedo  acquired  the 
target.  0  if  it  did  not  acquire  the  target. 

Air  Space: 

char  ( 5 ) 
mask:  LL-UU, 

where  LL  is  in  {00... 99)  and  DU  is  in  {01... 99) 
Indicates  the  altitude  range  reserved  in  the  opera¬ 
tional  area  for  participating  aviation  units. 

Brief  Title: 

char  ( 20 ) 

The  title  of  the  exercise  brief  to  be  given. 

Cance 1 ed : 

char  ( 25 ) 

One  of  6  reasons  why  an  event  was  cancelled  (asset 
availability,  fouled  range,  in trumen tation ,  wea¬ 
ther,  no  air  tracking,  no  show). 

Command : 

char  ( 8 ) 

The  designation  of  the  command  ( ie  VP-44,  SSN-680). 

Comments : 

char  ( 75 ) 

Narrative  remarks  pertaining  to  the  exercise  and  the 
exercise  results. 

Commun ications : 
char  ( 3 ) 

range :  in  { ' UHF '  ,  ' VHP '  ,  ' HF '  ) 

Frequency  range  to  be  used  for  exercise  communications. 
Default:  UHF 
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Compass ; 

number  (3),  integer 
range:  000-359 

Measured  in  degrees  true,  except  for  splashpt. 

Heading:  the  heading  of  the  platform  at  TOF . 

Sb:  the  platform's  solution  bearing  to  target. 

Sc:  the  platform's  solution  course  for  the  target. 
Splashpt:  relative  bearing  of  the  Meapon  splash  point 

from  the  target. 

Ta:  the  course  programmed  into  the  torpedo. 

Tb;  the  true  bearing  from  platform  to  the  target  at 
TOF. 

Tc:  the  true  compass  heading  of  the  target. 

Tm:  the  new  course  of  target  after  it  maneuvers  if 
maneuver  occurs  after  TOF  and  while  torpedo 
is  running. 

Contact  Code: 

char  ( 12 ) 

Indicates  how  the  platform  detected  and  maintained 

contact  with  target  (mad,  difar,  dicass,  ro, 
lofar,  dipper,  surfpass,  surfact,  ir,  vectac, 
spherical,  hull,  towed  array). 

Delivery  Code: 
char  ( 5 ) 

range:  svtt,  rtt  (asroc),  hover,  flyin,  tt,  asroc 
How  the  torpedo  was  delivered  to  the  splash  point. 

Depth : 

number  ( 4 ) 
range:  0-9999 

T;  the  depth  at  which  the  target  is  set  to  run. 

S:  the  depth  at  which  the  torpedo  is  set  to  search. 
Imp:  the  depth  at  which  the  tor pedo/ target  imploded 

(set  to  0  if  implosion  depth  is  unknown). 

Water:  the  depth  of  the  water  at  site  of  a  lost  weapon 

or  target. 

Doppler : 

char  ( 1 ) 
range:  1-5 

A  code  describing  the  type  and  amount  of  doppler  that 
the  target  has.  [  (1)  >  5kts,  (2)  2.5-5.0kts,  (3) 

2.5-(-2.5)kts,  (4)  (-2. 5)-(-5.0)  kts,  (5)  <  5kts]. 

Eva  1  : 

char  ( 10) 

Evaluation  as  to  whether  the  torpedo  hit  the  target, 
(hit,  prob  hit,  prob  miss,  miss,  unknown). 


Even  t ; 

number  ( 5 ) 

mask:  YYNNN ,  where  YY  are  the  last  two  digits  in  the 
year  and  NNN  is  the  sequential  number  of  that 
exercise  conducted  during  that  year. 

The  user-generated  code  identifying  the  specific  exer — 
c  ise . 


Exattain ; 

char  ( 1  ) 
range:  Y,  N 

Indicates  whether  or  not  the  range  achieved  its  objec¬ 
tive  for  the  exercise,  i.e.,  the  proper  services. 


Exc lusive : 

char  ( 1 ) 
range:  Y,  N 

Indicates  whether  or  not  the  event  has  exclusive  use  of 
the  operational  area. 

E  xdesc : 

char  ( 12 ) 

Narrative  description  of  the  exercise  to  be  conducted. 
Derived  from  exercise  publications. 


Exer  : 

char  ( 4 ) 

mask:  ANNN,  where  A  is  char  and  N  is  digit 
The  designation  of  the  type  of  exercise  to  be  conduc¬ 
ted.  Derived  from  exercise  publications. 

F  requenc  y ; 

char  ( 2 ) 
range:  NB ,  BB 

Indicates  whether  the  target  is  transmitting  mainly 
narrow  band  (NB)  or  broad  band  ( BB )  sounds.  N/A 
if  designation  is  a  ship. 

Geometry  Code: 
char  ( 4 ) 

The  code  for  the  geometry  programmed  into  the  target. 
(N/A  if  designation  is  a  ship  or  submarine). 


Height : 

number  ( 5 ) 
range:  0  -  99,999 

The  height  at  which  the  Mk-46  torpedo  was  launched.  For 
surface  ship.  Height  =  0. 
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Hours ; 

number  (2,1) 
range ;  .1-99 

Number  of  hours  that  were  lost  for  a  specific  reason 

canceled.  Recorded  as  hours  and  tenths  of  hours. 
Total  of  all  cancelled  hours  can  not  exceed  dif¬ 
ference  between  scheduled  start  time  and  scheduled 
stop  time. 


number  (2) 
range:  0-99 

Speed  measured  in  kts. 

Ts:  the  actual  speed  of  the  target  at  TOF. 

Tm:  the  speed  of  the  target  after  maneuver,  if  maneuver 
occurs  after  TOF  and  before  end  of  torpedo  run. 

Ss;  the  platform's  solution  of  speed  for  the  target. 


Lat 


char  ( 10 ) 


range : 


‘ : 

dd 

: mm : ss  N , 

'5  , 

ss 

seconds . 

dd 

20 

-  40 

mm 

0 

-  59 

ss 

0 

-  59 

where  dd  is  degrees. 


The  latitude  at  which  the  target  or  weapon  was 
All  latitudes  are  assumed  to  be  north  (N), 


mm  min- 


1  os  t , 


Launch : 

char  ( 7 ) 

The  designation  of  the  launch  vehicle  for  the  exercise 
target.  N/A  if  the  target  is  a  surface  ship  or  an 
actual  submarine. 


L inenumber : 

number  (3),  integer 

Identifies  unique  line  number  of  comments. 

Location ; 

char  (20) 

Provides  the  location  of  the  brief. 

Long i tude : 

char  (9) 

template  ddd:mm:ss  W 
range:  dd  0  -  180 

mm  0-59 
ss  0  -  59 

The  longitude  at  which  the  weapon  or  target  was  lost. 
All  longitudes  are  assumed  to  be  west  (W). 
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Message : 

c  har  ( i  ) 
range :  Y ,  N 

Req ;  indicates  whetner  or  not  a  "green"  tasking  mes¬ 
sage  needs  to  be  sent  to  the  participants  in  the 
exerc ise . 

Sent:  if  Req  =  Y,  indicates  whether  or  not  the  tasking 

message  has  been  sent.  N/A  if  Req  =  N. 

Sub:  indicates  whether  or  not  a  submarine  relaxation 

message  is  required  for  the  exercise. 


Minutes : 

number  (2,1) 
range:  0.0  -  60.0 

Maneuver;  the  time  in  minutes  after  TOP  at  which  the 
target  maneuvers.  If  no  maneuver  while  the  torpedo 
is  running  then  O  is  entered.  If  maneuver  occurs 
at  TOP  enter  0.1.  If  O  IS  entered,  skip  target 
maneuver  course  and  speed . 

Recover;  the  number  of  minutes  expended  by  the  reco¬ 
very  vehicle  in  retrieving  the  weapon  following 
tne  exercise. 

Search:  the  number  of  minutes  that  the  torpedo  was 

engaged  in  searching  for  the  target. 

Mk  : 

c  har  ( 8  ) 

range;  legal  rea 1 /simu 1  a ted  weapons  or  targets  from 
look  up  tables.  The  mk  of  the  weapon  or  target. 

Mod  : 

char  ( 5  ) 

range:  legal  mods  for  the  selected  torpedo 
The  mod  of  the  torpedo. 

Modecode  : 

char  ( 6 ) 

range:  snake'  or  circle' 

Mode  the  torpedo  uses  in  its  search. 

Nod  rop : 

char  ( 1 ) 
range;  a  -  i 

Letter  code  to  indicate  why  the  participant  did  not 
fire  all  of  his  scheduled  weapons.  (a-  platform 
problems,  b-  torpedo  problems,  c-  weather,  d- 
inadequate  recovery  assets,  e-  time  constraints, 
f-  fouled  range  g-  inadequate  TMA ,  h-  pinger 
problem,  i-  other). 
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Number : 

number  ( 1 ) 

S:  the  number  of  weapons  scheduled  to  be  dropped. 

U :  the  number  of  units  participating  in  an  exercise 

from  a  given  command. 

Oparea : 

char  (6) 

User — generated  title  for  the  area  in  which  the  exercise 
will  be  conducted. 


Personnel : 

char  ( 10 ) 

Brief:  briefer  assigned  to  conduct  designated  brief, 

□a:  operations  analyst  assigned  to  the  exercise. 

Op:  operation  controller  assigned  to  the  exercise. 

Pe :  project  engineer  assigned  to  the  exercise. 

S:  range  safety  officer  assigned  to  the  exercise. 


Ph: 

number  (3) 
range:  0-100 

Percent  rating  of  the  placement  of  the  weapon. 


Pinger ; 

char  ( 4  ) 

range:  in  ('nA',  'nB',  'nAnB'},  where  n 

Indicates  number  of  and  channel (s)  of 
signed  to  a  resource. 

T:  indicates  the  number  and  channel  of 

the  target. 

U:  indicates  the  number  and  channel  of 

the  participating  user  submarine. 

W:  indicates  the  number  and  channel  of 

the  weapon . 


is  an  integer 
pinger(s)  as- 

the  pinger  in 

pinger  used  by 

the  pinger  in 


Range : 

number  ( 5 ) 
range:  0  -  99,999 

Measured  in  yards. 

S:  the  platform's  solution  of  the  distance  at  TOP. 

Splashpt:  distance  from  the  splash  point  to  target. 

T;  actual  distance  of  target  from  platform  at  TOP. 


Recovered : 

char  ( 1 ) 
range :  Y  ,  N 

Indicates  whether  or  not  the  object  has  been  recovered. 
If  N,  then  the  LOST  object  is  used.  N/A  if  target 
designation  is  a  ship  . 
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Recovery : 

char  ( 8 ) 

The  designation  ot  the  recovery  vehicle  for  the  object 
(  ie  TRUJ-768  or  HC-1563).  N/A  if  target  designa¬ 
tion  is  a  ship. 

Haulback:  the  designated  weapon  haulback  vehicle. 

Pri:  primary  recovery  vehicle. 

Sec:  secondary  recovery  vehicle. 

Searc  h-seconds : 
number  (3) 
range:  0  -  999 

The  amount  of  time  the  weapon  was  in  its  search  phase. 

Seas  ta  te : 

number  ( 1 ) 
range:  0-9 

The  sea  state  as  measured  by  the  beaufort  scale. 

Serial  Number: 
char  ( 7  ) 

The  serial  number  of  the  torpedo. 

S ho wed  : 

char  (  1  ) 
range :  Y  ,  N 

Used  to  indicate  whether  or  not  the  scheduled  platform 
showed  up  for  the  exercise. 

S idenumber : 

char  ( 7  ) 

The  number  on  the 
1 1 f  y  it. 
squadron . 

Sonar  : 

char  ( 7 ) 

range :  active', 

The  type  of  sonar 

Sonobuoy  no . : 

number  (3) 
range:  0  -  999 

The  number  of  sonobuoys  of  a  particular  type  dropped  by 
a  plat  form . 


side  of  an 
Used  only 


If 


to  uniquely 
command  is  a 


1  den  - 


■passive,  combo,  actpass' 
detection  used  by  the  torpedo. 


Sound  : 

number  (3) 
range:  0  -  999 

Sound  level  of  target  measured  in  dB;  or,  the  augmenta¬ 
tion  sound  level  if  the  target  is  a  ship. 
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Speed : 

number  (3) 

range:  0  -  500  kts 

Speed  of  the  platform  at  time  of  attack. 

Target  Designation; 
c  har  ( 8 ) 

Indicates  the  type  of  target  used  in  the  exercise. 
Target  Performance; 
char  (20) 

Objective  evaluation  of  target  performance  during  the 
exercise.  ("Did  Not  Run",  "Floater",  etc.). 


T ime : 

char  (14) 

mask ;  ddhhmmZ  MONyy 
Brief:  scheduled  brief  time. 

C:  the  time  an  event  actually  starts  from  the  point  of 

view  of  the  range.  (Default:  sched  start  time). 

F:  the  time  an  event  actually  finishes  from  the  point 

of  view  of  range.  (Default:  sched  finish  time). 

Lost : 

Range:  comex  to  finex 

Time  at  which  the  weapon  or  target  was  lost 
L  : 

Range:  comex  to  finex 

Time  at  which  the  target  is  launched. 

MQCS  start;  scheduled  man-up  time  for  range  personnel. 
MOCS  stop:  scheduled  shut-down  time  for  range  per- 

sonne 1 . 

Schstart:  scheduled  exercise  start  time. 

Schstop:  scheduled  exercise  finish  time. 

Start: 

Def au 1 t :  comex 

Range:  comex  to  finex 

Time  at  which  the  platform  started  searching  for 
the  target  which  resulted  in  this  attack. 

Tof  : 

Default;  Date  part  to  comex. 

Range:  comex  to  finex. 

Time  of  fire  of  a  weapon. 

Torpperf ; 

char  ( 20 ) 

Indicates  the  performance  of  the  weapon  after  launch. 

(normal  run,  erratic  run,  did  not  run,  sank  at 
launch  point,  sank  at  end  of  run,  damaged). 
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Tr ac  k  Qua  1 i ty  : 

number  (3) 
range:  0  -  100 

The  percent  evaluation  of  the  quality  of  the  range's 
track  of  the  object.  (0  =  no  track,  100  =  perfect 
trac  k  )  . 

Tracking  Type: 

char  ( 1 ) 

range:  in  fe,  i,  b} 

The  type  of  tracking  to  be  used  during  the  exercise. 

(e  =  EATS,  i  =  in-water,  b  =  both). 

T  ransponder : 

char  ( 4 ) 

range:  IPIP,  SIP,  SAIP 

Indicates  the  type  of  transponder  with  which  the  plat¬ 
form  is  equipped.  N/A  for  submarines. 


Used  : 

char  (  1  ) 
range:  Y,  N 

Indicates  whether  or  not  a  scheduled  support  platform 
was  used  during  the  event. 


Visible : 

number  ( 2 ) 
range;  0-99 

The  visibility  on  the  range  in  nm.  (99  =  unlimited). 
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CREATE  NEW  EXERCISE  EVENT 
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APPENDIX  E 


UPDATE.  DISPLAY  AND  CONTROL  HECHANISMS 


A.  Schedule  Application 


EXERCISE  OBJECT 
Display  Hechanisms 


I.  Query  on  Exercise 

A.  Output  Description 

-  form  showing  all  data  for  a  given  exercise 
even  t 

B.  Source  Data 

-  EXERCISE  object 

C.  Processing  Notes 

-  EXERCISE  object  contains  USER,  WEAPON,  BRIEF 
and  TARGET  object  data 

D.  Volume 

-  five  per  week 

E.  Frequency 

-  daily,  as  needed 

II.  Weekly  Exercise  Schedule 

A.  Output  Description 

ORACLE  report  form  sent  to  all  concerned 

B.  Source  Data 

-  EXERCISE  object 

C.  Processing  Notes 

-  EXERCISE  object  contains  BRIEF,  USER,  WEAPON 
and  TARGET  objects 

D.  Volume 

-  25  per  week 

E.  Frequency 

-  once  per  week 
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III.  Modified  Weekly  Exercise  Schedule 

A.  Output  Description 

-  ORACLE  report  form  sent  to  all  concerned 

-  confirmation  message  on  screen 

B.  Source  Data 

current  Weekly  Exercise  Schedule 

-  EXERCISE  object 

Exercise  Type  and  Event  Number  keyed  by  PE 

C.  Processing  Notes 

~  BRIEF,  USER,  WEAPON  and  TARGET  objects  con¬ 
tained  within  associated  EXERCISE  object 

D.  Volume 


-  25  per  occurrence 

E.  Frequency 

-  daily,  as  needed 


EXERCISE  OBJECT 
Update  Mechanisms 


I.  Create  Exercise 

A.  Input  Description 

-  list  of  exercises  (from  monthly  planning 
sc  hedu le ) 

personnel  availability  (from  A-Base) 

-  range  availability  (from  E-Base) 

-  TARGET  object  data  (from  Project  Manager, 
NUWES,  and  Supporting  Commands) 

USER  object  data  (from  Project  Manager  and 
NUWES ) 

-  WEAPON  object  data  (from  Project  Manager  and 
Supporting  Commands) 

-  BRIEF  object  data  (from  Project  Manager) 

B.  Output  Description 

new  EXERCISE  object  in  database 
new  BRIEF  object  in  database 
new  USER  object  in  database 

-  new  WEAPON  object  in  database 

-  new  TARGET  object  in  database 

-  confirmation  message  on  screen 
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C.  Processing  Notes 

-  scheduler  needs  access  to  A-Base  and  E-Base 

D.  Volume 

-  normal  two  exercises  per  day,  five  days  per 
week 

E.  Frequency 

-  once  per  week 

II.  Modify  EXERCISE  Data 

A.  Input  Description 

changes  to  monthly  planning  schedule  (from  PM, 
NUWES,  and  Supporting  Commands) 
changes  to  personnel  availability  (from  (A- 
Base ) 

-  changes  to  range  availability  (from  E-Base) 

-  changes  to  scheduled  exercise  event  (from  PM, 
NUWES  and  Supporting  Commands) 

B.  Output  Description 

modified  EXERCISE  object  in  database 
modified  BRIEF  object  in  database 
modified  USER  object  in  database 
modified  WEAPON  object  in  database 
modified  TARGET  object  in  database 
confirmation  message  on  screen 
change  notice  sent  to  all  affected 

C.  Processing  Notes 

Project  Engineer  needs  access  to  A-Base  and  E- 
Base 

D.  Volume 

-  two  per  week 

E .  Frequency 

daily,  as  needed 

III.  Add/Edit  BRIEF  data  to  EXERCISE 

-  see  Update  Mechanisms  for  BRIEF 

IV.  Add/Edit  USER  data  to  EXERCISE 

-  see  Update  Mechanisms  for  USER 

V.  Add/Edit  WEAPON  data  to  EXERCISE 

-  see  Update  Mechanisms  for  WEAPON 

VI.  Add/Edit  TARGET  data  to  EXERCISE 

see  Update  Mechanisms  for  TARGET 
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VII.  Delete  EXERCISE  Event 

A.  Input  Description 

-  scheduled  exercise  event  to  be  cancelled  (from 
PM,  NUWES,  Supporting  Commands,  User) 

EXERCISE  object  in  database 

B.  Output  Description 

-  deletion  of  EXERCISE  object  from  database 

-  deletion  of  associated  BRIEF  objects  from 
database 

-  deletion  of  associated  USER  objects  from  data¬ 
base 

-  deletion  of  associated  WEAPON  objects  from 
database 

-  deletion  of  associated  TARGET  objects  from 
database 

-  confirmation  message  on  screen 
change  notice  sent  to  all  affected 

C.  Volume 

-  four  exercises  per  month 

D.  Frequency 

daily,  as  needed 


EXERCISE  OBJECT 
CONTROL  MECHANISMS 

I.  Provide  Password  Requirement  for  Security 

BRIEF  OBJECT 
Display  Mechanisms 


I.  Query  on  BRIEF 

A.  Output  Description 

-  form  showing  all  data  for  a  given  brief 

B.  Source  Data 

-  BRIEF  object  or  EXERCISE  object 

Exercise  Type  and  Event  Number  keyed  by  clerk 

C.  Processing  Notes 

used  by  scheduler 
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D.  Volume 

three  per  week 

E .  F  requenc  y 

-  daily,  as  needed 
II.  Weekly  Briefing  Report 

A.  Output  Description 

-  ORACLE  report  form  sent  to  all  concerned 

B.  Source  Data 

-  BRIEF  object  or  EXERCISE  object 

Exercise  Type  and  Event  Number  keyed  by  clerk 


C  . 


D  . 


.ng  Notes 

-  sent  to  all  concerned  when  weekly  schedule 
approved 
Vo  1 ume 


III. 


E  . 

Nod 

A  . 

B  . 


C  . 


D  . 


25  per  week 
F  requenc  y 

once  per  week 

ified  Weekly  Briefing  Report 
Output  Description 

ORACLE  report  form  sent  to  all  concerned 
Source  Data 

current  Weekly  Briefing  Report 
BRIEF  object  or  EXERCISE  object 

Exercise  Type  and  Event  Number  keyed  by  clerk 
Processing  Notes 

sent  to  all  concerned  when  changes  to  schedule 
approved 
Vo  1 ume 


25  per  week 
E .  F  requenc  y 

daily,  as  needed 


BRIEF  OBJECT 
Update  Mechanisms 


I  .  Create  Brief 

A.  Input  Description 

list  of  scheduleu  exercises  (from  0-Base) 


61 


-  list  of  required  briefs  for  scheduled  exercise 
(from  Project  Manager) 

room  location  and  availability  (from  E-Base) 
briefer  availability  (from  A-Base ) 

B.  Output  Description 

-  new  BRIEF  instance  in  database 

-  new  BRIEF  data  for  weekly  schedule 

-  new  BRIEF  Weekly  Report 

C.  Processing  Notes 

scheduler  needs  access  to  A-Base  and  E-Base 

D.  Volume 

-  minimum  two  briefs  per  exercise 
normal  two  exercises  per  day 

E .  F  requenc  y 

once  per  week  per  exercise 
I  I  .  Modify  BRIEF  Data 

A.  Input  Description 

-  changes  to  scheduled  events  (from  Project 
Manager,  NUWES,  Users,  Supporting  Commands) 

-  change  to  room  1 oc a t ion / avai 1 abi 1 i ty  (from  E- 
Base  ) 

change  in  briefer  availability  (from  A-Base) 
change  in  Brief  requirement  (from  Project 
Manager ) 

B.  Output  Description 

modified  BRIEF  object  instance  in  database 

-  modified  Weekly  Brief  Report 

C .  Vo  1 ume 

-  one  per  week 

D.  Frequency 

daily,  as  needed 
III.  Delete  BRIEF 

A.  Input  Description 

scheduled  exercise  to  be  cancelled  (from 
Project  Manager,  NUWES,  User) 

BRIEF  objects  in  database 

B.  Output  Description 

deletion  of  scheduled  briefs  from  database 

-  updated  Weekly  Brief  Report 
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updated  room  availability  in  E-Base 

-  updated  briefer  availability  in  A-Base 

C.  Processing  Notes 

scheduler  needs  access  to  A-Base  and  E-Base 

D.  Volume 

-  two  exsrcises  per  month 

-  minimum  two  briefs  per  exercise 

E .  Frequency 

daily,  as  needed 

BRIEF  OBJECT 
CONTROL  MECHANISMS 

Provide  Password  Requirement  for  Security 

USER  OBJECT 
Update  Mechanisms 


Create  USER 

A.  Input  Description 

Exercise  Type  and  Event  Number  (from  monthly 
sc  hedu 1 e  ) 

name  of  user  to  be  scheduled  for  exercise  event 
(from  PM  or  NUWES) 

number  of  units  from  a  given  user  to  be  sched¬ 
uled  for  exercise  event  (from  PM,  or  NUWES) 

-  list  of  authorized  users  (from  database) 

B.  Output  Description 

new  USER  object  in  database 

C.  Processing  Notes 

this  function  adds  USER  data  to  new  EXERCISE 
USER  object  is  created  by  scheduler  as  integral 
part  of  the  EXERCISE  object 

D.  Volume 

-  minimum  one  USER  per  event 
normal  10  events  per  week 
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E .  F  requency 

-  once  per  week  per  exercise  event 

II.  Modify  USER  Data 

A.  Input  Description 

-  change  in  number  of  units  of  participating 
command 

-  change  in  tracking  equipment  aboard  participa¬ 
ting  unit 

B.  Output  Description 

-  modified  USER  object  in  database 

-  modified  EXERCISE  object  in  database 

-  confirmation  message  on  screen 

-  change  notification  sent  to  all  affected 

C.  Processing  Notes 

this  process  changes  USER  data  and,  consequent¬ 
ly,  EXERCISE  data  for  scheduled  event 

-  Project  Engineer  makes  changes  to  USER  object 
when  making  changes  to  associated  EXERCISE 
obj  ec  t 

D.  Volume 

one  per  week 

E .  F  requency 

daily,  as  required 

III.  Delete  USER 

A.  Input  Description 

-  scheduled  user  to  be  deleted  from  exercise 
event  (from  PM,  NUWES ,  User  Command) 

-  EXERCISE  object  (from  database) 

-  USER  object  (embedded  in  EXERCISE  object) 

B.  Output  Description 

deletion  of  indicated  user  from  exercise  event 
deletion  of  indicated  USER  object  from  database 

-  confirmation  message  on  screen 
change  notice  sent  to  all  affected 

C.  Processing  Notes 

USER  object  also  deleted  with  deletion  of 
entire  exercise  event  (EXERCISE  object) 

WEAPON  object  (if  any)  should  also  be  deleted 

D.  Volume 

-  two  per  month 
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E. 


F  requency 

daily,  as  required 


USER  OBJECT 
Display  Mechanisms 

*  USER  object  is  not  normally  displayed  as  a  separate 
entity.  Rather,  it  is  embedded  within  the  associated  EXER¬ 
CISE  object. 


USER  OBJECT 
CONTROL  MECHANISMS 


I.  Provide  Password  Requirement  for  Security 


WEAPON  OBJECT 
Update  Mechanisms 


I  .  Create  WEAPON 

A.  Input  Description 

-  Exercise  Type,  Event  Number  and  Command  (from 
monthly  schedule) 

weapon  scheduled  for  exercise  event  (from  PM) 
list  of  authorized  weapons  (from  database) 

B.  Output  Description 

new  WEAPON  object  in  database 

C.  Processing  Notes 

-  WEAPON  object  is  created  by  scheduler  as  an 
integral  part  when  the  USER  object  is  created 

D.  Volume 

-  normal  two  WEAPON  objects  per  user 

-  minimum  one  user  per  event 

-  normal  10  events  per  week 

E.  Frequency 

minimum  once  per  week  per  exercise  event 
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II.  Modify  WEAPON  Data 

A.  Input  Description 

-  Exercise  Type,  Event  Number  and  Command 

-  change  in  WEAPON  data  ( from  PM  or  Supporting 
Command ) 

-  change  in  USER  data  (from  PM  or  NUWES ) 

B.  Output  Description 

-  modified  WEAPON  object  in  database 

-  modified  USER  object  in  database 
confirmation  message  on  screen 

-  change  notification  sent  to  all  affected 

C.  Processing  Notes 

-  this  process  changes  WEAPON  data  and,  conse¬ 
quently,  USER  object  data  for  a  given  scheduled 
even  t 

-  Project  Engineer  makes  changes  to  USER  object 
when  making  changes  to  associated  WEAPON  object 

D.  Volume 

-  one  per  week 

E.  Frequency 

daily,  as  required 

III.  Delete  WEAPON 

A.  Input  Description 

Exercise  Type,  Event  Number,  Command  Name 
weapon  to  be  deleted  (Mk) 

USER  object  (from  database) 

WEAPON  object  (embedded  within  USER  object) 

B.  Output  Description 

deletion  of  indicated  weapon(s)  from  exercise 
even  t 

deletion  of  indicated  WEAPON  object  from  data¬ 
base 

-  confirmation  message  on  screen 

-  change  notification  sent  to  all  affected 

C.  Processing  Notes 

WEAPON  object  is  also  deleted  with  deletion  of 
entire  exercise  event  (EXERCISE  object)  and 
with  the  deletion  of  a  user  (USER  object)  from 
an  exercise  event 
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D.  Volume 

-  two  per  month 

E.  Frequency 

-  daily,  as  required 


WEAPON  OBJECT 
Display  Hechanisms 


*  WEAPON  object  is  not  normally  displayed  as  a  sepa¬ 
rate  entity.  Rather,  it  is  embedded  within  its  associated 
USER  object. 


WEAPON  OBJECT 
CONTROL  MECHANISMS 


I.  Provide  Password  Requirement  for  Security 


TARGET  OBJEC  r 
Update  Mechanisms 


I  ,  Create  TARGET 

A.  Input  Description 

Exercise  Type  and  Event  Number  (from  monthly 
sc  hedu le ) 

target  to  be  scheduled  for  exercise  event 

(from  PM  or  NUWES ) 

list  of  targets  (from  database) 

B.  Output  Description 

new  TARGET  object  in  database 

C.  Processing  Notes 

TARGET  object  is  created  by  scheduler  as  an 
integral  part  when  the  EXERCISE  object  is 
c  reated 

D.  Volume 

-  minimum  one  TARGET  per  event 
normal  10  events  per  week 


67 


E.  Frequency 

-  minimum  once  per  week  per  exercise  event 

II.  Modify  TARGET  Data 

A.  Input  Description 

-  Exercise  Type  and  Event  Number 

-  change  in  Target  data  (from  PM  or  NUWES) 

B.  Output  Description 

modified  TARGET  object  in  database 
modified  EXERCISE  object  in  database 

-  confirmation  message  on  screen 

change  notification  sent  to  all  affected 

C.  Processing  Notes 

-  this  process  changes  TARGET  data  and,  conse¬ 
quently,  EXERCISE  object  data  for  a  given 
scheduled  event 

Project  Engineer  makes  changes  to  EXERCISE 
object  when  making  changes  to  associated 
TARGET  object 

D.  Volume 

one  per  week 

E.  Frequency 

daily,  as  required 

III.  Delete  TARGET 

A.  Input  Description 

-  Exercise  Type  and  Event  Number 

target  to  be  deleted  (from  PM  or  NUWES) 
EXERCISE  object  (from  database) 

TARGET  object  (embedded  within  EXERCISE  ob¬ 
ject) 

B.  Output  Description 

deletion  of  indicated  target  from  exercise 
even  t 

-  deletion  of  indicated  TARGET  object  from  data¬ 
base 

confirmation  message  on  screen 

change  notification  sent  to  all  affected 

C.  Processing  Notes 

TARGET  object  is  also  deleted  with  deletion  of 
entire  exercise  event  (EXERCISE  object) 
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D.  Volume 

-  two  per  month 

E.  Frequency 

daily,  as  required 


TARGET  OBJECT 
Display  Mechanisms 

*  TARGET  object  is  not  normally  displayed  as  a  sepa¬ 
rate  entity.  Rather,  it  is  embedded  within  its  associated 
EXERCISE  object. 


TARGET  OBJECT 
CONTROL  MECHANISMS 


I.  Provide  Password  Requirement  for  Security 


B.  Results  Application 

OPERATIONS  ANALYST  APPLICATION 
DISPLAY  MECHANISMS 


I.  Mon t h 1 y / Quar ter  1 y  Reports 

A.  Output  Description 

tables  for  monthly  and  quarterly  reports  on 
sc  reen 

-  tables  for  monthly  and  quarterly  reports 

B.  Source  Data 

-  RESULTS  object 

-  user  input  time  period  for  tables 

-  tables  desired 

C.  Processing  Notes 

-  use  menus  to  choose  which  table  to  print  and 
time  period  covered 

D.  Volume 

two  per  month 


69 


E.  Frequency 

-  monthly 
I  I .  TRIMS  Data 

A.  Output  Description 

-  ASCII  file  for  import  into  DB3+ 

-  screen  showing  TRIMS  data 

B.  Source  Data 

-  RESULTS  object 

C.  Processing  Notes 

-  ensure  all  exercise  entered  into  0-Base  before 
running 

D.  Volume 

-  once  per  month 

E.  Frequency 

-  monthly 

III.  Community  Reports 

A.  Output  Description 

screen  with  summary  data  presented 
paper  report  of  community  data 

B.  Source  Data 

-  RESULTS  object 

C.  Processing  Notes 

user  selects  time  period  and  community  to  be 
summar i zed 

D.  Volume 

five  per  quarter 

E.  Frequency 

-  quarterly 

OPERATIONS  ANALYST  APPLICATION 
CONTROL  MECHANISMS 

I.  Provide  Password  Requirement  for  Security. 
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ENTRY  CLERK  APPLICATION 
PLATFORM  Qbiect 
Update  Mechanisms 


I  .  Create  PLATFORM 

A.  Input  Description 

-  Exercise  Summary 

-  EXERCISE  object 

B.  Output  Description 

-  Exercise  Summary  neat 

-  new  instance  of  PLATFORM 

-  confirmation  message 

C.  Processing  Notes 

-  Platform  must  correspond  to  event  in  RESULT 

D .  Yo 1 ume 

-  two  per  event 

E.  Frequency 

-  once  per  day 
I  I .  Modify  PLATFORM 

A.  Input  Description 

-  PLATFORM  object  instance  from  database 
required  changes 

B.  Output  Description 

modified  objects 

updated  Event  Summary  neat 

C.  Processing  Notes 

any  changes  of  the  data  in  PLATFORM  can  cause 
instances  to  be  deleted  or  changed  from  ATTACK 
Ob j  ec  t 

D.  Volume 

-  two  per  week 

E.  Frequency 

-  weekly 

III.  Add/Edit  ATTACK  to  PLATFORM 

A.  See  Update  Mechanisms  for  ATTACK 
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PLATFORM  OBJECT 
Display  Mechanisms 


I  .  Query  on  PLATFORM 

II.  Output  Description 

-  form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

A.  Source  Data 

-  PLATFORM  object 

B.  Processing  Notes 

-  all  data  in  different  objects  must  be  joined 
together 

on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 

-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

C.  Volume 

-  four  per  day 

D.  Frequency 

daily 

III.  Exercise  Summary  neat 

A.  Output  Description 

computer  printed  exercise  summary 

format  to  be  similar  to  hand  written  exercise 

summary 

B.  Source  Data 

-  PLATFORM  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 

-  for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 


-  12  per  week 

E .  F  requency 
daily 
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PLATFORM  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE,  and  QA . 


ENTRY  CLERIC  APPLICATION 


I.  Create  ATTACK  Object 

A.  Input  Description 

-  Exercise  Summary 

-  EXERCISE  object 
5.  Output  Description 

Exercise  Summary  neat 
new  instance  of  ATTACK 
confirmation  message 

C.  Processing  Notes 

an  ATTACK  must  be  associated  with  a  PLATFORM 

D.  Volume 

four  per  event 
E  .  F requenc y 

once  per  day 
I  I  .  Modi f y  ATTACK 

A.  Input  Description 

-  ATTACK  object  instance  from  database 

-  required  changes 

B.  Output  Description 

-  modified  objects 

-  updated  Event  Summary  neat 

C.  Processing  Notes 

-  any  changes  of  the  data  in  ATTACK  can  cause 
instances  to  be  deleted  from  or  changed  in  LOST 
Object  and/or  WEAPON  RESULTS  Object. 

D.  Volume 

-  two  per  week 
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III. 


IV  . 


I . 


1 1 . 


E.  Frequency 
-  weekly 

Add/Edit  LOST  to  ATTACK 

A.  See  Update  Mechanisms  for  LOST  Object 
Add/Edit  WEAPON  RESULTS  to  ATTACK 

A.  See  Update  Mechanisms  for  WEAPON  RESULTS 


ATTACK  Object 
Display  Mechanisms 


Query  on  ATTACK 

A.  Output  Description 

-  form  showing  ail  data  for  a  given  event 

-  same  form  as  for  input  of  data 

B.  Source  Data 

ATTACK  object 

C.  Processing  Notes 

all  data  in  different  objects  must  be  joined 
together 

on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 

-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

D.  Volume 

-  four  per  day 

E .  Frequency 

-  daily 

Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  Exercise  Summary 

-  format  to  be  similar  to  hand  written  Exercise 
Summary 

B.  Source  Data 

-  ATTACK  object 

C.  Processing  Notes 

used  by  Program  Engineer  to  check  data  and 
paper  record 
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D. 


•for  each  new  instance  and  modified  instance  one 
is  made 


Vo  1 ume 

12  per  week 
E.  Frequency 
-  daily 

ATTACK  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE  and  OA . 


ENTRY  CLERK  APPLICATION 
WEAPON  RESULTS  Object 
Update  Mechanisms 

I.  Create  WEAPON  RESULTS  Object 

A.  Input  Description 

Exercise  Summary 

-  EXERCISE  object 

B.  Output  Description 

Exercise  Summary  neat 

new  instance  of  WEAPON  RESULTS 

-  confirmation  message 

C.  Processing  Notes 

-  a  WEAPON  must  correspond  to  a  TOF  in  ATTACK 
if  a  Platform  performs  a  simulated  attack  no 
weapon  results  is  created 

D.  Volume 

three  per  event 

E.  Frequency 

once  per  day 
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II.  Modify  WEAPON  RESULTS 

A.  Input  Description 

WEAPON  RESULTS  object  instance  from  database 
required  changes 

B.  Output  Description 

-  modified  objects 

-  updated  Exercise  Summary  neat 

C.  Processing  Notes 

-  any  changes  of  the  data  in  WEAPON  RESULTS  can 
cause  instances  to  be  deleted  from  or  changed 
in  LOST  object 

D .  Vo  1 ume 

-  two  per  week 

E .  F  r equenc  y 

-  week  1  y 

III.  Add /Ed  It  LOST  to  WEAPON  RESULTS 

A.  See  Update  Mechanisms  for  LOST  Object 

WEAPON  RESULTS  OBJECT 
Display  Mechanisms 

I  .  QL;ery  on  WEAPON  RESULTS 

A.  Output  Description 

form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

B.  Source  Data 

WEAPON  RESULTS  object 
L.  Processing  Notes 

all  data  in  different  objects  must  be  joined 
together 

on  querying  a  multi-valued  field  must  show  cr 
indicate  other  occurrences 

on  querying  a  non-key  field  must  indicate  other 
occurrences 
D  .  Vc  Kj me 

tour  per  day 
F  .  f  r  eguer-c  y 


d  a  1  1  y 


II.  Exercise  Summary  neat 

A.  Output  Description 

computer  printed  Exercise  Summary 

-  format  to  be  similar  to  hand  written  Exercise 
Summary 

B.  Source  Data 

-  WEAPON  RESULTS  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 

for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 

12  per  week 

E .  F  requency 

daily 


WEAPON  RESULTS  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  tc  PE  and  OA . 

ENTRY  CLERK  APPLICATION 


I.  Create  TARGET  RESULTS  Object 

A.  Input  Description 

Exercise  Summary 
EXERCISE  object 

B.  Output  Description 

Exercise  Summary  neat 

new  instance  of  TARGET  RESULTS 

confirmation  message 
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C.  Processing  Notes 

a  target  must  correspond  to  event  in  RESULT 

D.  Volume 

-  one  per  event 

E.  Frequency 

-  once  per  day 

II.  Modify  TARGET  RESULTS 

A.  Input  Description 

-  TARGET  RESULTS  object  instance  from  database 

-  required  changes 

B.  Output  Description 

-  modified  objects 

C.  Updated  Exercise  Summary  neat 

D.  Processing  Notes 

-  any  changes  of  the  data  in  TARGET  RESULTS  can 
cause  instances  to  be  deleted  from  or  changed 
in  LOST  object 

E .  Vo  1 ume 

-  two  per  week 

F.  Frequency 

week  1  y 

III.  Add/Edit  LOST  to  TARGET  RESULTS 

A.  See  Update  Mechanisms  for  LOST 

TARGET  RESULTS  OBJECT 
Display  Mechanisms 


I.  Query  on  TARGET  RESULTS 

A.  Output  Description 

-  form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

B.  Source  Data 

-  TARGET  RESULTS  object 

C.  Processing  Notes 

all  data  in  different  objects  must  be  joined 
together 

on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 
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-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

D.  Volume 

-  four  per  day 

E.  Frequency 

-  dai  ly 

II.  Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  Exercise  Summary 

-  format  to  be  similar  to  hand  written  Exercise 
Summary 

B.  Source  Data 

-  TARGET  RESULTS  object 

C.  Processing  Notes 

used  by  Program  Engineer  to  check  data  and 
paper  record 

-  for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 

12  per  week 

E .  Frequency 

daily 

TARGET  RESULTS  OBJECT 
Control  ligchanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE  and  OA . 

ENTRY  CLERK  APPLICATION 
LOST  Object 
Update  Mechanisms 

I  .  Create  LOST 

A.  Input  Description 

-  Exercise  Summary 
EXERCISE  object 
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B.  Output  Description 

Exercise  Summary  neat 
new  instance  of  LOST 

-  confirmation  message 

C.  Processing  Notes 

a  LOST  must  correspond  to  a  MK  and  Serial  in 
WEAPON  RESULTS  or  TARGET  RESULTS 

D.  Volume 

-  four  per  year 

E.  Frequency 

once  per  quarter 
I  I .  Modify  LOST 

A.  Input  Description 

-  LOST  object  instance  from  database 

-  required  changes 

B.  Output  Description 

-  modified  objects 

-  updated  event  summary  neat 

C.  Processing  Notes 

any  changes  of  the  data  in  WEAPON  RESULTS  or 
TARGET  RESULTS  can  cause  instances  to  be  de¬ 
leted  or  changed  from  LOST  object 

D.  Volume 

four  per  year 

E .  Frequency 

semi-annually 

LOST  OBJECT 
Display  Mechanisms 


I  .  Query  on  LOST 

A.  Output  Description 

-  form  showing  all  data  for  a  given  event 
same  form  as  for  input  of  data 

B.  Source  Data 

LOST  object 

C.  Processing  Notes 

all  data  in  different  objects  must  be  joined 
toge  t  her 
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-  on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 

-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

D.  Volume 

-  two  per  month 

E.  Frequency 

-  monthly 

II.  Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  exercise  summary 

-  format  to  be  similar  to  hand  written  exercise 
summary 

B.  Source  Data 

LOST  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 

for  each  new  instance  and  modified  instance  one 
is  made 

D .  Vo lume 

12  per  week 

E .  Frequency 

daily 

LOST  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE,  and  OA . 
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APPENDIX  F 


RELATION  DIAGRAMS 


A.  Schedule  Application 


EXERCISE 


03 


B.  Results  Application 


RESULT 
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APPENDIX  G 

LOGICAL  MENU  STRUCTURE 

SCHEDULE  APPLICATION 


MAIN  MENU 


B.  RESULTS  APPLICATION 


print! 
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APPENDIX  H 


ORACLE  TABLES 


A.  APPLICATION  TABLES 


EXERCISE  TABLE 


Name 

Nu  11?  ’’’ype 

EXER 

NOT  NULL  CHAR(4) 

EVENT 

NOT  NULL  NUMBER! 5) 

EXDESC 

CHAR( 12) 

SSTART 

CHAR ( 14 ) 

SSTOP 

CHAR ( 14 ) 

MSTART 

CHAR( 14  ) 

MSTOP 

CHAR( 14 ) 

Cr  AREA 

CHAR (6) 

tracktype 

CHAR! 1 ) 

PROJENG 

CHAR! 10) 

OPCQN 

CHAR ( 10 ) 

OPANAL 

CHAR  110) 

SAFEOFF 

CHAR ! 10 ) 

TPRIREC 

CHAR! 7 ) 

TSECREC 

CHAR  1 7 ) 

WPRIREC 

CHAR ! 7 ) 

WSECREC 

CHAR! 7 ) 

HAULBACK 

CHAR ! 7 ) 

GRNREQ 

CHAR ! 1 ) 

GRNSENT 

CHAR! 1 ) 

SUBRLX 

CHAR ! 1 ) 

AIRSPACE 

CHAR ! 5 ) 

CONN 

CHAR ! 3 ) 

EXCLUS 

CHAR ! 1  ) 
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SCH  COMMENT  TABLE 


Name 

Null? 

Type 

EXER 

NOT 

NULL 

CHAR(4 ) 

EVENT 

NOT 

NULL 

NUMBER( 5) 

LINENO 

NOT 

NULL 

NUMBER! 3) 

COMMENTS 

CHAR (75) 

BRIEF  TABLE 


Name 

Null? 

Type 

EXER 

NOT 

NULL 

CHAR ( 4 ) 

EVENT 

NOT 

NULL 

NUMBER! 

TITLE 

NOT 

NULL 

CHAR ( 20 

TIME 

CHAR( 14 

LOCATION 

CHAR (20 

BRIEFER 

CHAR( 10 

TARGET  TABLE 


Name 

Null? 

Type 

EXER 

NOT  NULL 

CHAR ( 4 ) 

EVENT 

NOT  NULL 

NUMBER! 

TGTDESIG 

NOT  NULL 

CHAR! 8) 

GEOMETRY 

CHAR! 4 ) 

ACOUSTICS 

CHAR! 1 ) 

TPINGER 

CHAR ! 4 ) 

LNCHVEH 

CHAR! 8) 
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USER  TABLE 


Name 


Nu 11?  Type 


EXER 

EVENT 

COMMAND 

UNUMBER 

TRANSPONDER 

UPINGER 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
NOT  NULL  CHAR(8) 

NUMBER ( 1 ) 
CHAR(4 ) 
CHAR(4) 


WEAPON  TABLE 


Name  Null?  Type 


EXER 

NOT 

NULL 

CHAR ( 4 ; 

EVENT 

NOT 

NULL 

NUMBER ( 5 ) 

Mk; 

NOT 

NULL 

CHAR ( 5 ) 

COMMANl' 

NOT 

NULL 

CHAR ( 8 ) 

SNuMBER 

NUMBER ( 1 ) 

WP I NGEP 

CHAR ( 4 ) 

RESULT  TABLE 

Name 

Null? 

T  ype 

E  X  E  R 

NOT  NULL 

CHAR ( 4 ) 

EVENT 

NOT  NULL 

NUMBER ( 5 ) 

EXDESC 

CHAR ( 12 ) 

COMEX 

CHAR ( 14 ) 

F  I  NE  X 

CHAR ( 14 ) 

SSTART 

CHAR {  14  ) 

SSTOP 

CHAR( 14 ) 

□PAREA 

CHAR ( 6 ) 

vis: BuE 

NUMBER  ^  2  I 
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SEASTATE 

EXCOMMENTS 

TABLE 

NUMBER! 1 ) 

Name 

Null? 

Type 

EXER 

EVENT 

LINENO 

COMMENTS 

NOT  NULL 

NOT  NULL 

CHAR ( 4 ) 

NUMBER ( 5 ) 

NUMBER ( 3 ) 

CHAR (75) 

CLASSCMTS 

TABLE 

Name 

Null? 

Type 

EXER 

EVENT 

LINENO 

COMMENTS 

NOT  NULL 

NOT  NULL 

CHAR(4 ) 

NUMBER! 5) 

NUMBER! 3) 

CHAR (75) 

SUPPORT 

TABLE 

Name 

Null? 

Type 

EXER 

EVENT 

SPLATFORM 

SSIDENO 

NOT  NULL 

NOT  NULL 

CHAR! 4 ) 

NUMBER! 5) 

CHAR (8) 

CHAR! 7 ) 

USED  CHAR(l) 
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CANCEL  TABLE 


Name 


Nu 11?  Type 


EXER 

EVENT 

CANCEL 

HOURLOST 

CANCELTIME 


NOT  NULL  CHAR(4) 

NOT  NULL  NUMBER(5) 
CHAR (25) 
NUMBER ( 2, i ) 
CHAR (14 ) 


PLATFORM  TABLE 


Name  Null"’  Type 


EXER 

NOT  NULL  CHAR(4) 

EVENT 

NOT  NULL  NUMBER(5) 

COMMAND 

CHAR(8) 

SIDENO 

CHAR(7 ) 

- 

SHOWED 

CHAR( 1 ) 

TRACKQP 

NUMBER ( 3 ) 

LOFAR 

NUMBER( 3) 

DIFAR 

NUMBER(3) 

DICAS 

NUMBER(3) 

VLAD 

NUMBER ( 3 ) 

SCHWEP  TABLE 

Name 

Nu 11?  T  ype 

EXER 

NOT  NULL  CHAR(4) 

EVENT 

NOT  NULL  NUMBER(5) 

- 

COMMAND 

CHAR(8) 

SIDENO 

CHAR(7) 

WEAPON 

CHAR( 5) 

SNUMBER 

NUMBER ( 2 ) 
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NODROP 


Name 


EXER 

EVENT 

TOP 

COMMAND 

SIDENO 

STARTOP 

TGTCOURSE 

TGTBY 

TGTSPEED 

TGTRANGE 

TGTDEPTH 

TGTMANT IME 

TGTMANC0UR5E 

TGTMANSPEED 

SBY 

SCOURGE 

SSPEED 

GRANGE 

HEADTOF 

SPEEDTOF 

ALTITUDE 

MODECODE 

SONARSET 

CONTACT 

DELIVERY 

SPLASHBY 

SPLASHRH 

ACQUIRED 

ATTACKEVAL 

SEARCHDEPTH 

DOPPLER 

PH 


ATTACK  TABLE 


CHAR ( 1 ) 


Nu 11?  T  y pe 


NOT  NULL  CHAR(4) 

NOT  NULL  NUMBER! 5) 
CHAR! 14) 
CHAR! 8) 
CHAR!?) 
CHAR! 14 ) 
NUMBER!3) 
NUMBER! 3) 
NUMBER!?) 
NUMBER! 5 ) 
NUMBER! 4  ) 
NUMBER!?, 1 ) 
NUMBER! 3 ) 
NUMBER!?) 
NUMBER! 3) 
NUMBER! 3) 
NUMBER!?) 
NUMBER! 5 ) 
NUMBER! 3) 
NUMBER! 3) 
NUMBER! 5 ) 
CHAR! 6) 
CHAR! 7 ) 
CHAR! 1?) 
CHAR! 5) 
NUMBER! 3) 
NUMBER! 5) 
CHAR! 1  ) 
CHAR! 10) 
NUMBER! 4  ) 
CHAR! 1  ) 
NUMBER! 1 ,? ) 


9? 


ATTCQMMENTS  TABLE 


Name 


Null?  Type 


TOP 

LINENO 

COMMENTS 


NOT  NULL  CHAR (14) 
NUMBER ( 3 ) 
CHAR (75) 


WEAPONR  TABLE 


Name 


Nu 11?  T  ype 


TOP 

MK 

serial 

MOD 

TORPPERP 

SEARCH! 

WEPREC 

RECVEH 

RECTIME 

BBVEH 

TRACKQL 


CHAR( 14 ) 
CHAR( 5) 
CHAR ( 7 ) 
CHAR ( 5 ) 
CHAR ( 20 ) 
NUMBER! 3) 
CHAR( 1 ) 
CHAR (8) 
NUMBER! 2 ) 
CHAR(8) 
NUMBER! 3 ) 
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LOST  TABLE 


Name 

Nu 11?  Type 

MK 

CHAR(5) 

SERIAL 

CHAR ( 7 ) 

TOF 

CHAR ( 14 ) 

EXER 

CHAR(4) 

EVENT 

NUMBER! 5) 

MOD 

CHAR ( 5 ) 

LAT 

CHAR ( 10) 

LONGITUDE 

CHAR( 10) 

IMPLOSION 

NUMBER! 4 ) 

WDEPTH 

NUMBER! 5) 

TIMELOSS 

CHAR! 14) 

FROMBLOCK 

CHAR! 1 ) 

TAR6ETR  TABLE 


Name 

Nu 11?  Type 

EXER 

CHAR! 4 ) 

EVENT 

NUMBER! 5 ) 

TGTDESIG 

CHAR ! 8 ) 

SERIAL 

CHAR! 7 ) 

TGTPERF 

CHAR! 20) 

GEOMETRY 

CHAR! 4 ) 

TOF 

CHAR! 14 ) 

TGTREC 

CHAR! 1 ) 

RECVEH 

CHAR!8) 

DB 

NUMBER! 3) 

FREQ 

CHAR! 2) 

TRACKQT 

NUMBER! 3) 

MOD 

CHAR! 5) 
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B.  LOOK-UP  TABLES 


Name 


CANCELLOOKUP 

Null? 


CANCELLOOKUP 


CANCEL  (Legal  Values) 


ASSET  AVAILABILITY 
FOULED  RANGE 
INSTRUMENTATION 
WEATHER 

NO  AIR  TRACKING 
NO  SHOW 


CONTACTLOOKUP 


Name 


Null? 


CONTACT 


CONTACT  (Legal  Values) 


MAD 

DIFAR 

DICASS 

RANGE  ONLY 

LOFAR 

DIPPER 

SURFPASS 


SURFACT 

IR 

VECTAC 

SPHERICAL 

HULL 

TOWED  ARRAY 


Type 


CHAR (25) 


Type 


CHAR( 12 ) 
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DELIVERYLOOKUP 


Name 


Null? 


DEL  IV 


DELIVERY  (Legal  Values) 


SVTT 

RTT 

HOVER 

FLYIN 

TT 

ASRQC 


EVALLOOKUP 

Name  Nu 11? 


EVAL 


EVAL  (Legal  Values) 


HIT 

PRQB  HIT 
PRQB  MISS 
MISS 
UNKNOWN 


Type 


CHAR ( 5 ) 


Type 


CHAR( 10) 


96 


LINENUMBER 


Name 

Null? 

Type 

TABLENAME 

CHAR ( 15) 

EXER 

CHAR ( 4 ) 

EVENT 

CHAR ( 5 ) 

LINENO 

NUMBER! 3) 

TABLENAME 

EXER 

EVENT  LINENO 

SCH 

_COMMENT 

A601 

89004 

1 

SCH 

_COMMENT 

A601 

89005 

1 

SCH 

_COMMENT 

A612 

88082 

7 

SCH 

_COMMENT 

S610 

89001 

1 

PERFLOOKUP 

Name 

Null? 

Type 

PERF  CHAR (20) 


PERF  (Legal  Values) 


NORMAL  RUN 

ERRATIC  RUN 

DID  NOT  RUN 

SANK  AT  LAUNCH  POINT 

SANK  AT  END  OF  RUN 

DAMAGED 

SEE  COMMENTS 
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RECuVLOOKUP 


Type 


Name  Nu  11? 


RECOV 


RECO  (Legal  Values) 


TWR 

HC-1 


SONARLODKUP 


Name 


Null? 


SONAR 


SONAR  (Legal  Values) 


ACTIVE 

PASSIVE 

COr^BQ 

ACTPASS 


CHAR(4) 


Type 


CHAR ( 7 ) 
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APPENDIX  I 


VARIABLE  ASSOCIATIONS 


EXERCISE  OBJECT 


Descriptive  Name _ Domain  Name _ Variable  Name 


Exercise  Type 

Exer 

EXER 

Event  Number 

Event 

EVENT 

Exercise  Description 

Exdesc 

EXDESC 

Schedule  Start  Time 

T ime-Schstart 

SSTART 

Schedule  Stop  Time 

T ime-Sc  hstop 

SSTOP 

MQCS  Start  Time 

Time-MOCS  Start 

MSTART 

NQCS  Stop  Time 

Time-MOCS  Stop 

MSTOP 

Operational  Area 

Oparea 

OPAREA 

Exc 1 usi ve  Use 

Primary  Target 

Exc 1 usi ve 

EXCLUS 

Recovery  Vehicle 
Secondaiy  Target 

Recovery-Pri 

TPRIREC 

Recovery  Vehicle 
Primary  Weapon 

Recovery-Sec 

TSECREC 

Recovery  Vehicle 
Secondary  Weapon 

Recovery-Pr i 

WPRIREC 

Recovery  Vehicle 
Weapori  Haulback 

Recovery-Sec 

WSECREC 

Vehic  le 

Recovery-Hau I bac  k 

HAULBACK 

Tracking  Type 

Tracking  Type 

TRACKTYPE 

Project  Engineer 

Personnel -Pe 

PROJENG 

Operation  Controller 

Personnel -Or 

OPCON 

Operation  Analyst 

Personnel -Oa 

OPANAL 

Safety  Officer 

Personnel -So 

SAFEOFF 

Green  Required 

Message -Req 

GRNREQ 

Green  Sent 

Submarine  Relaxation 

Mess age -Sen  t 

GRNSENT 

Message 

Message-Sub 

SUBRLX 

Air  Space 

Air  Space 

AIRSPACE 

Communications 

Communications 

COMM 

Commen  ts 

Commen  ts 

COMMENTS 

BRIEF:  BRIEF  object; 

MV 

USERS:  USER  object;  MV 

TARGET:  TARGET  object; 

RESULTS:  RESULTS  object 

MV 
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BRIEF  OBJECT 


Descriptive  Name 

Domain  Name 

Variable  Name 

Brief  Title 

Brief  Title 

TITLE 

Brief  T ime 

T ime-Br lef 

TIME 

Location 

Location 

LOCATION 

Briefer 

Personne 1 -Brief 

BRIEFER 

Descriptive  Name 

USERS  OBJECT 

Domain  Name 

Variable  Name 

Exercise  Type 

Exer 

EXER 

Event  Number 

Even  t 

EVENT 

Command  Name 

Command 

COMMAND 

Number  of  Units 

Number-U 

UNUMBER 

EATS  Transponder 

T  ransponder 

TRANSPONDER 

Pinger  Channel 

WEAPON:  WEAPON  object; 

P inger-U 

MV 

UPINGER 

Descriptive  Name 

TARGET  OBJECT 

Domain  Name 

Variable  Name 

E xerc 1 se  Type 

Exer 

EXER 

Event  Number 

Even  t 

EVENT 

Target  Designation 

Target  Designation 

TGTDESIG 

Geome  try 

Geometry  Code 

geometry 

Ac  oust  1 c  s 

Acoustics 

ACOUSTICS 

Pinger 

Pinger-T 

TPINGER 

Launch  Vehicle 

Launc  h 

LNCHVEH 

WEAPON  OBJECT 

Descriptive  Name 

Domain  Name 

Variable  Name 

Mk 

Mk 

MK 

Command  Name 

Command 

COMMAND 

Number  Scheduled 

Number-S 

snumber 

Pinger 

Pinger-W 

WRINGER 
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RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 
Event  Number 
Exercise  Description 
Exercise  Attainment 
Come  X 
F  inex 

Scheduled  Start  Time 
Scheduled  Stop  Time 


Operational  Area 

Visibility 

Sea  State 

Reason  Canceled  MV 

Hours  Lost  MV 

Cancel  Start  Time  MV 

Support  Platform  MV 

Support  Side  Number  MV 
Support  Used  MV 

Classified  Comments 
Unclassified  Comments 


E  xer 
Event 
E  xdesc 
Exattain 
T ime-C 
T ime-F 

T ime-Sc  hstar t 

T ime-Schstop 

Oparea 

Visible 

Seastate 

Canceled 

Hours 

T ime-Cance 1 
Command 
Sidenumber 
Used 

Commen  ts 
Comments 


PLATFORM;  PLATFORM  object;  MV 

TAROFf  RESULTS;  TARGET  RESULTS  object;  MV 


Descriptive  Name 

E  xerc 1 se  T y pe 
Event  Number 
Command  Name 
Side  Number 
Showed  Up 
T rac  ^  Qua  1 i ty 
Lof  ar 
Di  f  ar 
Dicass 
Vlad 

Weapon  Assigned  MV 
Number  of  Weapons 
Scheduled  MV 

No  Drop  MV 

ATTACK;  ATTACK  cbje 


PLATFORM  OBJECT 

Domain  Name 


Exer 
Even  t 
Command 
S 1 denumber 
Showed 

T  rac  k  Oua 1 i ty 
Sonobuoy  no. 
Sonobuoy  no. 
Sonobuoy  no. 
Sonobuoy  no. 
Mk 

Nurober-S 

Nodrop 

t  ;  MV 


Variable  Name 

EXER 

EVENT 

EXDESC 

EXATTAIN 

COMEX 

FINEX 

SSTART 

SSTOP 

OPAREA 

VISIBLE 

SEASTATE 

CANCEL 

HOURLOST 

CANCELTIME 

SPLATFORM 

SSIDENO 

USED 

COMMENTS 

COMMENTS 


Variable  Name 

EXER 

EVENT 

COMMAND 

SIDENO 

SHOWED 

TRACKQP 

LOFAR 

DIFAR 

DICAS 

VLAD 

WEAPON 

SNUMBER 

NODROP 
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TARGET  RESULTS  OBJECT 


Descriptive  Name 

Domain  Name 

Variable  Name 

Exercise  Type 

Exer 

EXER 

Event  Number 

Event 

EVENT 

Target  Designation 

Target  Designation 

TGTDESIG 

Mod 

Mod 

MOD 

Serial  Number 

Serial  Number 

SERIAL 

Target  Performance 

Target  Performance 

1GTPERF 

Geometry 

Geometry  Code 

GEOMETRY 

Launch  Time 

T ime-L 

TOF 

Target  Recovered 

Recovered 

TGTREC 

Recovery  Vehicle 

Recovery 

RECVEH 

Sound  Level 

Sound 

DB 

F  requency 

Frequency 

FREQ 

Track  Quality 

Track  Quality 

TRACKQT 

LOST;  LOST  object 


Descriotive  Name 

WEAPON  RESULTS  OBJECT 

Domain  Name 

Variable  Name 

Time  of  Fire 

TOF 

TOF 

Mk 

Mk 

MK 

Mod 

Mod 

MOD 

Serial  Number 

Serial  Number 

SERIAL 

Torpedo  Performance 

Torpperf 

TORPPERF 

Search  T ime 

Search-Seconds 

SEARCH 

Weapon  Recovered 

Recovered 

WEPREC 

Recovery  Vehicle 

Recovery 

RECVEH 

Recovery  T ime 

Minutes-Recover 

RECT IME 

Bring  Back  Vehicle 

Recovery 

BBVEH 

Track  Qua  1 i ty 

Track  Quality 

TRACKQW 

LOST;  LOST  object 

Descriotive  Name 

LOST  OBJECT 

Domain  Name 

Variable  Name 

Mk 

Mk 

MK 

Mod 

Mod 

MOD 

Serial  Number 

Serial  Number 

SERIAL 

T ime  Lost 

T ime-Lost 

TIMELOST 

Lati tude 

Lat 

LAT 

Long i tude 

Long 

LONGITUDE 

I mp 1 osion 

Depth- Imp 

IMPLOSION 

Water  Depth 

Depth-Water 

WDEPTH 

ATTACK  OBJECT 


DescriDtive  Name 

Domain  Name 

Variable  Name 

Time  of  Fire 

T ime-Tof 

TOF 

Command  Name 

Command 

COMMAND 

Side  Number 

Sidenumber 

SIDENO 

Start  Op 

T ime-Star t-time 

STARTOP 

Actual  Target  Course 

Compass-T  c 

TGTCOURSE 

Actual  Target  Bearing 

Compass-Tb 

TGTBY 

Actual  Target  Speed 

Kts~Ts 

TGTSPEED 

Actual  Target  Range 

Range-T 

TGTRANGE 

Actual  Target  Depth 

Depth-T 

TGTDEPTH 

Target  Maneuver  Time 
Target  Maneuver 

Minutes-Maneuver 

TGTMANTIME 

Course 

Target  Maneuver 

Compass-T  m 

TGTMANCOURSE 

Speed 

Kts-Tm 

TGTMANSPEED 

Target  Doppler 

Doppler 

TGTDOPLER 

Solution  Bearing 

Compass-Sb 

SBY 

Solution  Course 

Compass-Sc 

SCOURSE 

Solution  Speed 

Kts-S 

SSPEED 

Solution  Range 

Range-S 

GRANGE 

Heading  at  TQF 

Compass-Heading 

HEADTOF 

Speed  at  TOF 

Speed 

SPEEDTOF 

A 1 t i tude 

Height 

ALTITUDE 

Mode 

Modecode 

MODECODE 

Sonar  Setting 

Sonar 

SONARSET 

Contact  Type 

Contact  Code 

CONTACT 

Delivery  Method 

De 1 i very  Code 

DELIVERY 

Bearing  to  Splash  Point 

Compass-Splashpt 

SPLASHBY 

Range  to  Splash  Point 

Range-Sp 1 ashpt 

SPLASHRH 

Acqu i red 

Acquired 

ACQUIRED 

Eval  of  Attack 

Eval 

ATTACKEVAL 

Search  Depth 

Depth-S 

SEARCHDEPTH 

Comments  MV 

Comments 

COMMENTS 

Line  Number  MV 

WEAPON  RESULTS;  WEAPON 

Linenumber 

RESULTS  object; 

LINENO 
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APPENDIX  J 


SCREEN  DESIGNS 
SCHEDULE  APPLICATION 

INPUT  NEN  EVENT  DATA 

- f - 4. - 

:  EIERCISE  TYPE:  _  EVENT  NUNBER:  _  ! 

1  EIERCISE  DESCRIPTION:  _  1 


4 - 4 

EIERCISE  TINES: 


SCHEDULED  START: 
NOCS  NAN-UP: 


SCHEDULED  FINISH: 
NOCS  SriUT-DOHN: 


SPfAATtSNAL  ARIA  AISISNEDl 


EICLUSIVE  U9E7I 


EIERCISE  PERSONNEL: 

PROJECT  EN6INEER: 

OPERATION  CONTROL: 

OPERATION  ANALYST: 

SAFETY  OFFICER: 

4 . 4” - - 4 - 


NISCELLANEOUS  EVENT  DATA 

EVENT  NUNBER; 


;  EIERCISE  TYPE 
4 

TRACItlNe  TYPE: 


4 - - 4 


EVENT  NESSA6ES: 

6REEN  REQUIRED'’:  _  BREEN  SENT?: 

SUBNARINE  RELAIATION  NESSA6E  REQUIRED?: 


AIR  SPACE  RESTRICTIONS: 
CONNUNICATIONS: 
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EVENT  SU<>PI»T  VEHICLES 


EXERCISE  TYPEi  _  EVENT  NUNBERi 


TRRSET  SUPPORT  VEHICLESi 


PRIMARY  TARGET  RECOVERY*.  _ 

SECONDARY  TARGET  RECOVERY i  _ 

NEAPON  SUPPORT  VEHICLES: 


PRIMARY  NEAPON  RECOVERY:  _ 

SECONDARY  NEAPON  RECOVERY:  _ 

NEAPON  HAULBACK:  _ 
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ENTER  USER  DATA 


EXERCISE  TYPE  I  _  EVENT  NUNBERi 


NAME  OF  COHNANDl  _ 

NUNBER  Of  UNITS  I  __ 

PIN6ER  CHAfWELt  _ 

(IF  8UBHARINE) 

TRANSPONOER-EflUIPPED?:  _ 

(IF  AIR  OR  SURFACE) 


TYPE  OF  NEAPON 
(HK) 


NUNBER 

SCHEDULED 


PINSER 

CHANNEL 


B.  RESULTS  APPLICATION 


+ - - ♦ 

;  E  X  E  R  C  I  S  E  S  U  N  H  A  R  Y  1 

+ - - ♦ 

:  EXERCISE  _  EVERT  _ _  EXERCISE  DESCRIPTIOR  _  I 

<  I 

1  I 

!  OPAREA  _  1 

1  COHEX  _  VISIBILITY  _ 

1  FIREX  _  SEA  STATE  _  1 

- - - 

;  REASOR  CARCELED  HOURS  TIHE  OF  1 

!  LOST  CANCELLATION  ! 


♦ . . . - . ♦ 

:  LAUNCH/RECOVERY  ASSETS  ! 


PLATFORR  SIDE  NUNBER  USED 


♦ . . 


USER  DATA 


EXERCISE 

COHNAND  DESI6NATI0N 

SIDE  NUNBER 

SHONED  FOR  EXERCISE 

TRACK  QUALITY  _ 

SONOBOUY  USASEi  LOFAR 

DIFAR 

DICAS 

VLAD 

— 

HEAPON  TYPE 

RUHBER 

REASON 

SCHEDULED 

ROT  DROPPED 

lOB 


ATTACK 


A  T  A 


TARGET  DATA 

SOLUTION  DATA 

FIRING  UNIT  DATA 

COURSE  _ 

COURSE  _ 

COURSE  _ 

BEARING  _ 

BEARING  _ 

SPEED  __ 

RANGE 

RANGE 

ALTITUDE 

SPEED  _ 

SPEED  _ 

DEPTH 

♦ . 4 

t  DOPPLER  _  : 

NANEUVERi  I  ; 

TIRE  .  . . . 

:  COURSE  _  ; 

!  SPEED  _  ! 

- - - 


ATTACK  DATA 

- - - - - ... — - - ...... 

:  EJERCISE _ UNIT  _ SIDE  NUMBER  _ TOP 

- - 

!  firing  DATA  RESULTS 

;  CONTACT  TYPE  _  ACBUIRED 

1  ATTACK  RODE  _  ATTACK  EVAL  1. 

1  SONAR  SETTING  _  PH  _ 

I  DELIVERY  RODE  _  SPLASH  BEARING  __ 

1  SEARCH  DEPTH  _  SPLASH  RANGE  _ 

4 - - - - - - - - — ............ 

ATTACK  CONNENTSi 
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WEAPON 


A  T  A 


* . . . ♦ 

I  EXERCISE _ UNIT  _  SIDE  NUMBER  _  TOP _ 1 

♦ - - ♦ 

!  HK  _  HOD  _  SERIAL  _  I 

:  TRACK  DUALITY  _  TORPEDO  PERFORMANCE  _  1 


WEAPON  RECOVEREDIY.N) 

SEARCH  TIME  _  RECOVER  VEHICLE 


;  TIME  TO  RECOVER  _  BRINS  BACK  VEHICLE  _ 

- - - 


TARGET  DATA 


- - - - .... - - - - - - - - - ^ 

1  EXERCISE  _  : 

♦ . . 

‘  I 

1  TARGET  DESIGNATION  _  HOD  _  SERIAL  NUMBER  _  1 

i  I 

:  LAUNCH  TIME  _  TRACK  DUALITY  __  i 

t  I 

;  PERFORMANCE  _  GEOMETRY  _  1 

I  I 

1  SOUND  LEVEL  _  FREDUENCY  BAND  _  1 

I  I 

1  RECOVERED(Y,Nl  _  RECOVERY  VEHICLE  _  ! 


LOST  TARGETS  AND  WEAPONS 

EXERCISE _ MK  _  MOD _  SERIAL  NUMBER 

TOF  _ 

TIME  OF  LOSS  _ _ 

LATITUDE  _ 

LONGITUDE  _ 

IMPLOSION  DtPTH  _ 

WATER  DEPTH  _ 
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UNCLASSIFIED  C  0  N  H  E  N  T  B 

EXERCISE 
;  CONNENTS 


I 

I 


I 

I 


CLASSIFIED  CONNENTS 


EXERCISE 


APPENDIX  K 


SYSTEM  USER  MANUAL 


In  troduc  tion ; 

This  manual  introduces  and  explains  the  operation  of 
the  two  0-Base  applications.  These  applications  are  de¬ 
signed  to  minimize  the  effort  required  for  data  entry.  They 
also  provide  the  ability  to  modify,  delete  and  query  the 
database.  The  Schedule  application  stores  the  event  data 
that  make  up  the  schedule,  and  provides  an  easy  method  for 
making  changes  to  the  event  data  as  circumstances  change  or 
more  information  becomes  available.  The  Results  application 
stores  information  about  what  occurred  during  an  event.  This 
information  can  then  be  queried  or  used  to  produce  various 
reports . 

About  This  Manual; 


This  manual  is  designed  to  guide  you  to  in  using  the 
system.  It  assumes  that  you  have  completed  the  SQL*FDRMS 
Operator's  Guide  tutorial,  and  are  familiar  with  the  various 
terms  used  in  that  manual.  If  you  are  unfamiliar  with  the 
terms  block,  record,  form  and  query,  refer  to  the  SQLKiFORMS 
Operators's  Guide. 

This  user  manual  contains  two  parts.  Part  I  covers  the 
Schedule  application  and  Part  II  the  Results  application. 
Each  part  is  divided  into  seven  sections;  1)  Introduction, 
2)  Description  of  the  form,  3)  Add  procedures,  A)  Modify 
procedures,  5)  Delete  procedures,  6)  Querying  the  database, 
and  7)  Detailed  description  of  each  field.  The  most  useful 
section  will  be  the  detailed  field  descriptions,  because  it 
describes  ‘-nw  each  field  operates.  This  section  should  be 
kept  handy  as  a  reference  even,  for  experienced  operators. 

Conventions  and  General  Operating  Procedures; 

•  When  a  function  key  is  described  in  the  manual,  the 
Oracle  name  will  be  given  first,  followed  by  the 
IBM/MS-DOS  keyboard  name  enclosed  in  <  > . 

•  When  entering  data  into  a  field,  a  Next  Field  <Enter> 
moves  the  cursor  to  the  next  available  field. 

•  When  entering  a  field,  a  short  help  message  appears  at 
the  bottom  of  the  screen. 
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Starting  the  Applications; 

To  start  the  application,  make  sure  that  Oracle  was 
started  properly.  Then,  type  either  Schedule  or  Results 
fallowed  by  a  carriage  return  <cr>.  This  will  start  the 
appropriate  application.  You  will  then  be  asked  for  your 
name  and  password.  Enter  your  name  and  password  followed  by 
a  carriage  return  <cr>.  If  you  do  not  have  or  forget  your 
password  see  your  Database  Administrator. 
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PART  I 


SCHEDULE  APPLICATION 


1 .  I n  t roduc  t ion  ; 


This  application  stores  each  scheduled  event  into  the 
database  so  that  a  schedule  can  be  constructed.  The  proce¬ 
dure  for  entering  data  has  been  made  as  simple  as  possible. 
You  type  in  the  data  you  wish  to  enter  and  then  press  the 
Enter  <cr>  key.  The  most  important  information  entered  is 
the  exercise  type  and  the  event  number,  since  this  informa¬ 
tion  determines  the  event  to  which  you  are  referring.  Upon 
entering  a  new  event  the  system  will  automatically  give  you 
an  event  number  based  on  the  year  in  which  it  is  scheduled. 
Once  the  system  knows  what  event  to  which  you  are  referring, 
you  may  either  add,  modify,  or  delete  information  from  that 
even  t  . 

2 .  Form  Description; 

The  schedule  contains  six  blocks:  Exercise,  Brief, 
Users,  Weapon,  Target,  and  Comments.  These  blocks  are  the 
basic  subdivision  used  by  SQL*FORnS.  This  grouping  of 
information  allows  for  quicker  navigation.  Using  the  Next 
Block  <page  down>  and  Previous  Block  <page  up>  any  block  may 
be  accessed  quickly. 

The  exercise  data  block  is  the  first  block  ahd  contains 
three  pages  of  data.  The  first  page  contains  the  exercise, 
event  number  and  scheduled  start  and  stop  times  along  with 
other  general  event  information.  The  second  page  contains 
tracking  requi remen ts ,  and  message  information,  while  the 
third  contains  information  on  recovery  vehicles. 

The  next  block  is  the  Brief  block.  It  contains  infor¬ 
mation  on  briefs  associated  with  the  event.  This  block  is 
set  up  to  allow  multiple  briefs  to  be  entered  for  an  event. 
Entering  nothing  into  the  block  will  move  you  directly  to 
the  User  Block. 

The  User  block  contains  information  about  the  commands 
scheduled  to  use  the  range  durian  this  even^-.  Many  users 
can  be  involved  in  a  single  even t .  To  v i ew  other  users,  the 
Next  Record  key  <down  arrow>  can  be  used  to  scroll  both  the 
user  and  the  weapons  associated  with  it.  Entering  a  blank 
in  the  command  field  will  move  you  to  the  Target  block, 
while  next  block  will  move  you  to  the  Weapon  block. 

The  Weapon  block  is  on  the  same  page  as  the  User  block. 
This  arrangement  allows  the  weapons  data  to  be  viewed  with 
their  respective  user.  This  block  allows  you  to  view  two 
weapons  at  a  time  and,  as  indicated  above,  Next  Record  <down 
arrow>  and  Previous  Record  <up  arrow>  can  be  use  to  scroll 
the  records . 


The  Target  block,  located  on  page  four,  allows  entry  of 
data  pertaining  the  target  scheduled  for  an  event. 

The  last  block  is  the  Comments  block  which  contains 
notes  on  the  event.  Upon  completion  of  this  block,  all  data 
entered  is  automatically  stored  into  the  database. 

3 .  Add  Procedures: 

This  section  describes  how  new  data  is  entered  into  the 
system.  This  is  a  general  description  of  the  process  and 
should  be  used  in  conjunction  with  the  detailed  field  de¬ 
scriptions.  Before  starting  to  enter  new  data,  you  should 
have  at  hand  all  of  the  information  you  are  going  to  enter, 
particularly  the  exercise,  user,  and  target  information. 

Step  1.  Start  at  the  top  of  the  form  (  If  not  at  top  of 
form,  select  Previous  Block  <page  up>  until  you  get  a  mes¬ 
sage  saying  "top  of  form"  on  the  status  line).  Select 
Create  Record  <F9> ,  which  sets  up  the  form  to  enter  a  new 
record . 

Step  2.  Enter  your  exercise  type  and  the  last  two  digits 
of  the  year  in  which  the  event  will  occur.  This  allows  the 
system  to  calculate  the  proper  event  number. 

Step  3.  Enter  your  data,  field  by  field  as  described  in 
the  detailed  field  descriptions. 

Step  4.  Qnce  you  are  in  the  Brief  Block  enter  your  infor¬ 
mation  regarding  the  first  brief.  After  entering  the  brie¬ 
fer,  the  block  will  clear  and  the  cursor  repositions  to  the 
brief  title  field.  You  can  enter  another  brief  or,  if  fin¬ 
ished  entering  briefs,  press  return.  You  will  now  be  at  the 
top  of  the  User  block.  Enter  your  user  data. 

Step  5.  After  entering  your  user  data,  you  are  presented 
with  the  Weapon  block.  Enter  the  data  for  the  first  weapon. 
Following  the  pinger  channel  entry,  the  cursor  will  reposi¬ 
tion  under  the  first  weapon  entered.  Continue  entering  data 
for  all  weapons  scheduled.  Pressing  return  on  an  empty  "Type 
of  Weapon"  field  will  return  you  to  a  blank  User  block.  You 
have  the  option  of  entering  another  user  or  nothing.  If  you 
entered  all  your  users  then  enter  nothing  and  move  to  the 
target  block . 

Step  6.  Enter  your  target  data.  When  finished  you  will 
move  into  the  Comments  block.  Enter  your  comments,  pressing 
return  twice  when  finished.  All  data  entered  is  stored  and 
you  are  returned  again  to  the  first  screen. 


116 


4  .  Modify  Procedures: 

Modifying  an  existing  entry  is  straightf orward .  First, 
retrieye  (see  Querying  the  Database)  the  event  to  the 
screen,  then  change  or  add  data  as  if  you  were  entering  data 
for  the  first  time.  The  exception  to  this  procedure  is  that 
you  can  not  change  exercise  or  event  numbers.  To  enter  a 
new  brief  or  user  you  must  either  select  Create  Record<F9> 
or  Next  Field  <enter>  until  a  blank  record  appears  on  the 
screen.  To  add  a  weapon  to  an  existing  command  go  to  the 
User  block  and  select  Next  Record  <down  arrow>  until  the 
desired  user  name  appears.  Then  use  Next  Field  <enter>  to 
moye  to  an  blank  weapon  line  and  enter  the  information.  To 
add  an  additional  target,  go  to  the  Target  block  and  select 
Next  Record  <enter>  or  Create  Record  <F9> ,  and  enter  the 
information.  To  add  additional  comments  just  add  them  to 
the  previous  comments.  Note  howeyer,  blank  lines  are  not 
allowed.  If  you  want  to  separate  comments,  use  some  key¬ 
board  symbol,  such  as  " * " ,  or  "="  on  a  line  to  sep¬ 
arate  them. 

5 ■  Delete  Procedures; 

Delete  works  on  many  leyels;  you  can  delete  an  entire 
event  or  any  of  its  yarious  objects  (Brief,  Users,  etc.). 

To  delete  an  entire  eyent  you  must  first  be  in  the 
Exercise  block  then  retrieye  the  desired  record  as  described 
in  the  next  section.  Once  the  desired  eyent  is  displayed 
select  Delete  Record  <shift  F5>.  This  will  delete  the 
entire  event  including  any  Briefs,  Users,  Targets  and  Com¬ 
ments  associated  with  the  event. 

Any  record  in  the  other  blocks  can  be  deleted  in  the 
same  manner.  First,  display  the  record  to  be  deleted,  then 
select  delete  record.  When  deleting  a  User  the  Weapons 
associated  with  that  User  are  also  deleted.  In  the  comments 
block  selecting  delete  record  will  only  delete  one  line  at  a 
t  i  me  . 


6 .  Query  Database; 

The  ability  to  query  the  database  in  this  application 
is  limited.  In  all  blocks  except  the  Exercise  block  que¬ 
ries  are  constrained  by  the  exercise  type  and  event  number 
displayed.  For  example,  if  you  are  in  the  Brief  block,  the 
only  records  retrieved  in  response  to  a  query  will  be  those 
associated  with  the  exercise  type  and  event  number  displayed 
at  the  top  of  the  block.  Even  with  this  limitation  many 
useful  queries  may  be  done. 

The  easiest  query  to  perform  is  a  general  query.  This 
retrieves  all  records.  To  do  this  you  must  be  in  the  Exer¬ 
cise  block.  Then  select  Execute  Query  <F2> ,  which  will 


retrieve  all  events.  They  may  then  be  viewed  sequentially  by 
selecting  Next  Record  <down  arrow>. 

The  other  type  of  query  is  a  selected  query,  through 
which  you  retrieve  records  that  satisfy  certain  selection 
criteria  (For  example,  exercise  type  =  "Torpex").  This  is 
also  done  from  the  Exercise  block.  Select  Enter  Query  <F1> 
and  enter  the  selection  criteria  into  the  fields  that  you 
wish  to  query,  then  select  Execute  Query  <F2> .  One  example 
would  be  to  query  all  data  relevant  to  a  particular  exer — 
cise.  The  procedure  would  be:  (1)  Enter  Query  <F1>,  (2) 
enter  the  exercise  type  and  the  event  number,  and  (3)  select 
Execute  Query  <F2> .  This  would  either  retrieve  the  record 
or  say  no  record  selected,  in  which  case  you  can  enter 
another  query.  More  complex  queries  are  possible  and  are 
described  in  the  SQL^FQRMS  Operator's  guide  chapter  11. 

7 .  Detailed  Field  Descriptions: 

This  section  provides  a  quick  reference  on  each  field 
and  shows  the  screen  layouts. 


EitrclM  Block  (Pagt  111 


♦ . . 

!  INPUT  NEH  EVENT  DATA  I 

♦ . ♦ . . . ♦ . ♦ 

1  1  ElERCISE  TYPEi  _  EVENT  NUHBERi  _  :  1 

:  1  EXERCISE  DESCRIPTION!  _  !  1 


. . . 

EXERCISE  TIHESi 

SCHEDULED  START:  _  SCHEDULED  FINISH!  _ 

NOCS  NAN-UPi  _  ROCS  SHUT-DONN: 


;  EXERCISE  PERSONNEL:  1 

>  I 

PROJECT  ENSINEERi  _  ; 

OPERATION  CONTROL!  _  ; 

OPERATION  ANALYST  I  _  | 

:  =*FETY  OFFICERi  _  ! 

♦ . . ♦ 

I  I 

;  OPERATIONAL  AREA  ASSISNEDi  _  EXCLUSIVE  USE?:  ! 


Fields; 

Exercise  Type:  Enter  the  type  of  exercise  to  be  scheduled. 

List  Values  <F4>  can  be  used  to  review  standard  exer¬ 
cises.  This  field  is  mandatory. 
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Event  Number:  In  this  field  the  only  input  allowed  are  the 

last  two  digits  of  the  year  in  which  the  exercise  will 
occur.  Once  this  data  is  entered,  the  proper  event 
number  is  automatically  generated.  This  field  is 
mandatory . 

Exercise  Description:  This  field  is  automatically  filled 

in  based  on  the  exercise,  but  may  be  changed  to  fit  the 
actual  exercise  needs. 

Schedule  Start;  Enter  the  schedule  start  time  in  standard 
military  date-time  group  format  DDHHMMZ  MQNYY.  Where 
DD  is  the  day  of  the  month,  HHMM  is  military  time,  Z  is 
the  time  zone  (San  Diego  is  U  time),  MON  is  the  three 
letter  abbreviation  for  the  month,  and  YY  is  the  last 
two  digits  of  the  year.  Entering  the  wrong  format  will 
cause  an  error  message  to  be  displayed.  To  get  more 
information  on  the  error  Display  Error  <shift-F10>. 

Scheduled  Finish:  This  is  the  scheduled  stop  time  for  the 
event.  It  has  to  be  in  the  standard  format  described 
above . 

MOCS  Man-up;  This  is  the  time  that  the  MOCS  should  be 
manned  up.  The  default  is  one  hour  before  the  sched¬ 
uled  start  time.  This  must  be  in  standard  format 
DDHHMMZ  MQNYY. 

MOCS  shut-down;  This  is  the  time  scheduled  to  shut  down 
the  MOCS.  The  default  is  one  hour  after  scheduled 
finish.  This  is  also  entered  in  standard  format. 

Exercise  Personnel;  These  four  fields  are  used  to  indicate 
the  personnel  scheduled  for  the  event.  You  may  enter 
either  initials  or  up  to  10  characters  of  their  name. 

Operational  Area;  The  scheduled  operational  area  of  the 
even  t . 

Exclusive  Use:  This  Y/N  field  indicates  if  the  operational 
area  is  reserved  exclusively  for  the  exercise. 
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Extrciii  Block  (Pigi  2)t 


HISCELLANEOUS  EVENT  DATA 


1  EIERCISE  TYPEi  _ 

+ - 

TRACKIN6  TYPEi 


EVENT  NUNBERi 


EVENT  HE8SA6ES1 

BREEN  REQUIRED?:  .  BREEN  SENT?: 

6UBNARINE  RELAXATION  NE88A6E  REQUIRED?! 


AIR  8PACE  RESTRICTIONS: 
CONNUNICATIONSi  _ 


F ie 1 ds : 

Exercise,  Event:  These  fields  are  are  replicated  from  the 

first  page  and  cannot  be  entered. 

Tracking  Type:  The  type  of  tracking  required  for  the 

event.  Enter  E  for  EATS  tracking,  I  for  in-water  or 
B  for  both. 

Green  Required:  Is  a  rainform  green  message  required. 

Enter  either  Y  or  N.  If  one  is  not  required,  the  fol¬ 
lowing  Green  Sent  field  is  skipped. 

Green  Sent:  This  field  defaults  to  N  and  should  be  changed 

to  Y  when  the  required  rainform  green  message  is  sent. 

Submarine  Relaxation:  This  is  used  to  indicate  if  a  sub¬ 

marine  relaxation  message  is  required,  either  Y  or  N. 

Air  Space  Restrictions:  This  field  states  the  altitude 

limits  for  aircraft  involved  in  the  event.  The  heights 
are  in  hundreds  of  feet  with  the  low  altitude  first. 
For  instance  if  the  allowable  altitude  was  O  to  5000  ft 
the  entry  would  be  00-50. 

Communications:  This  is  the  primary  frequency  for  com¬ 

munication  during  the  exercise,  usually  UHF . 
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Exirciil  Block  (Page  3)i 


:  EVENT  SUPPORT  VEHICLES 

♦ - - - - - - +— ♦ 

1  I  EJERCISE  TYPE:  _  EVENT  NUNBERt  _  1  1 

I  ♦ - ♦  ; 

t  j 

;  TARGET  SUPPORT  VEHICLES!  ! 


PRIMARY  TARGET  RECOVERY!  _ 

SECONDARY  TARGET  RECOVERY:  _ 

NEAPON  SUPPORT  VEHICLES! 


PRIMARY  NEAPON  RECOVERY! 
SECONDARY  NEAPON  RECOVERY! 
NEAPON  HAULBACK: 


Fields: 

Exercise,  Event:  These  fields  are  replicated  from  the  first 
page  and  cannot  be  entered. 

Recovery  Vehicles:  These  five  fields  are  for  listing  the 

primary  and  secondary  vehicles  scheduled  to  provide 
support  to  the  event.  In  each  field  enter  the  name  of 
the  command  that  will  provide  that  support.  List 
Values  <F4>  may  be  used  to  list  commonly  used  commands. 
After  weapon  haul  back  is  entered  you  will  move  to  the 
Brief  Block. 
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Brilf  Block  (Ptgc  4)i 


1  EXERCISE  TYPE: 

EVENT  NUHBERi 

■••A 

INPUT  EXERCISE  BRIEF  DATA 


TITLE  OF  BRIEF  I 
TIHEi 
LOCATION: 
BRIEFER: 


Fields: 

Exercise,  Event:  These  fields  are  replicated  from  the  first 
page  and  cannot  be  entered. 

Title  of  Brief:  Enter  the  title  of  the  brief.  Leaving 

this  field  bldnt  will  move  yow  direo tly  to  the  Meer 
Block . 

Time;  Enter  the  scheduled  time  of  the  brief  in  standard 
date-time  group  format  DDHHMM2  MONYY.  See  Exercise 
block  scheduled  start  field  for  details  of  the  date¬ 
time  format. 

Location:  Enter  the  location  where  the  brief  will  be  held. 

Briefer;  Enter  the  Name  of  the  person  who  will  give  the 

brief.  After  entering  this  field  you  will  move  back  to 
the  Title  of  Brief  field,  allowing  you  to  enter  another 
brief . 


Uiir  Block  (Pigt  9)i 


ENTER  USER  DATA 


1  EXERCISE  TYPEi  _  EVENT  NUNBERi 


;  NAME  OF  CONNANDi 

I 
I 

:  NUNBER  OF  UNITSi 

I 
I 

1  PINSER  CHANNEL I 

!  (IF  SUBNARINE) 

I 

1  TRANSPONDER-EQUIPPED?! 

:  (IF  AIR  OR  SURFACE) 

. . . 


TYPE  OF  NEAPON  NUNBER  PINBER 

(NX)  SCHEDULED  CHANNEL 


Fields: 

Exercise,  Event;  These  fields  are  replicated  from  the 

first  page  and  cannot  be  entered. 

Name  of  Command:  Enter  the  name  of  the  command,  using 

command  designations  ( ie  VP-44,  SSN-6B0 ) .  If  you  leave 
this  field  blank  the  system  assumes  that  you  have 
entered  all  the  commands  for  this  event  and  moves  you 
to  the  Target  Block. 

Number  of  Units;  This  field  is  entered  only  if  the  command 
is  an  aircraft  squadron.  Enter  the  number  of  aircraft 
from  this  command  that  will  participate  in  the  event. 

Pinger  Channel:  This  field  is  entered  only  if  the  command 

is  a  submarine.  Enter  the  pinger  channel  to  be  in¬ 
stalled  on  the  sub.  From  this  field  you  move  directly 
to  the  Weapon  block  on  the  same  page. 

Trans  onder  Equipped:  This  applies  only  to  ships  and 

aircraft.  Enter  the  type  of  transponder  to  be  in¬ 
stalled.  After  entering  this  field  you  move  to  the 
Weapon  block  on  the  same  page. 
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Weapon  Block: 


Fields: 


Type  of  Weapon:  Enter  the  type  of  weapon  scheduled  for  this 
command.  Leaving  this  field  blank  will  move  you  back 
to  the  user  block  allowing  you  to  enter  another 
command . 

Number  Scheduled:  Enter  the  number  of  weapons  of  this  type 

sc  hedu 1 ed . 

Finger  channel:  Enter  the  pinger  channels  to  be  used  by 

the  weapons.  If  four  weapons  are  scheduled,  two  with  A 
pingers  and  two  with  B  pingers,  then  enter  2A2B .  After 
entering  this  field  you  will  move  back  to  Type  of 
Weapon  field  allowing  another  type  of  weapon  to  be 
scheduled  for  this  user. 


Tirgit  Block  (Pigi  6)i 


ENTER  TARGET  DATA 

EXERCISE  TYPE:  _ 

EVENT  NUNBER:  _ 

TARGET  DESIGNATION: 

GEORETRY  CODE:  _ 

PROPER  ACOUSTICS?: 

PINGER  CHANNEL: 

TARGET  LAUNCH  VEHICLE: 

Fields: 

Exercise,  Event: 


These  fields  are  replicated  from  page  1. 


Target  Designation:  This  field  contains  the  designation  of 

the  target.  If  the  target  is  a  ship  or  submarine  the 
designation  is  just  its  command.  If  it  is  a  mechanical 


target ,  enter 

its 

NK  number.  If  the  target 

is  a 

shi  p 

or  submarine, 

the 

remainder  if  the  block  is 

not 

ap- 

plicable,  and 
block  . 

you 

will  move  directly  to  the 

Commen  t 

Geometry  code: 
target . 

Enter 

the  geometry  programmed 
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into 

the 

Proper  Acoustics:  Verify  that  the  target  has  the  proper 

acoustics,  either  Y  or  N. 

Pinger  channel:  Enter  the  pinger  channel  to  be  used  by  the 

target . 

Target  Launch  Vehicle:  Enter  the  command  that  will  launch 

the  target.  After  entering  this  field  you  will  move  to 
the  Comments  Block. 


CoMinti  Block  (Pigi  7)i 

4 - - - f 


COMMENTS 


Fields: 

Comments:  This  field  allows  you  to  enter  any  comments 

pertaining  to  the  event.  You  may  use  as  many  lines  as 
necessary.  To  move  to  the  Next  Line  select  enter  <cr>. 
To  move  to  the  Next  Block  select  enter  <cr>  twice.  You 
will  then  be  at  the  top  of  the  form  in  the  Exercise 
block. 
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PART  I I  RESULTS 


1 ■  IntrQduc  tion : 

This  application  stores  the  data  recorded  during  the 
event  so  that  it  can  be  reviewed  and  analyzed  later.  It 
also  allows  the  user  to  query  and  generate  reports  on  the 
stored  data.  As  with  the  schedule  application,  it  was 
designed  to  minimize  the  effort  required  for  data  entry. 
The  same  <enter>  key  will  move  you  through  the  entire  form. 
Before  an  event  can  be  entered  it  must  first  exist  in  the 
Schedule  application,  ensuring  that  data  can  pass  between 
the  two  applications.  This  application  is  much  larger  that 
Schedule  and  has  more  blocks,  but  should  be  no  more  complex 
to  operate. 

2 .  Form  Description; 

The  form  contains  13  blocks  on  nine  screen  pages.  The 
blocks  are  Result,  Cancel,  Launch/Recovery,  User,  Scheduled 
Weapons,  Attack,  Attack  Comments,  Weapon,  Target,  Unclas¬ 
sified  Comments,  Classified  Comments,  and  Lost. 

The  Result  block  is  the  first  and  master  block.  It 
contains  the  exercise  type  and  event  number,  along  with  the 
oparea,  comex ,  finex  and  weather  information.  This  is  the 
only  block  from  which  you  can  query  multiple  events. 

The  next  two  blocks,  Canceled  and  Launch/Recovery,  are 
also  on  page  one.  Canceled  is  for  entering  reasons  why  part 
or  all  of  an  event  was  canceled.  The  Launch  and  Recovery 
block  records  whether  or  not  a  scheduled  recovery  vehicle 
was  used.  Both  of  these  blocks  are  multi-record  blocks, 
showing  up  to  three  cancellations  and  four  recovery  vehicles 
at  once.  As  in  all  other  multi-record  blocks  entering 
nothing  moves  you  to  the  next  block. 

□n  page  two  are  the  User  and  Scheduled  Weapon  blocks. 
The  User  block  records  the  actual  platform  that  was  on  the 
range.  From  this  block,  you  move  into  the  Scheduled  Weapon 
block  which  is  a  multi-record  block. 

The  Attack  block  on  page  three  is  one  of  the  most 
important  because  it  records  all  the  attack  data  for  the 
command  in  the  User  block.  This  block  covers  two  pages  and 
leads  directly  into  Attack  Comments.  These  comments  go 
directly  with  the  attack  described  above  it. 

Moving  to  page  five,  we  start  to  see  the  complex  navi¬ 
gation  controls  of  this  application.  The  path  so  far  has 
moved  directly  through  the  form.  Attacks  can  involve  actual 
or  simulated  weapons.  If  the  attack  was  simulated  you  will 
return  to  the  Attack  block,  allowing  you  to  enter  another 
attack.  Otherwise  you  may  enter  Weapon  data,  which,  upon 
completion,  will  also  bring  you  back  to  the  Attack  block. 
If  there  are  no  more  attacks  conducted  by  this  platform  you 
will  return  to  the  User  block  were  another  platform  may  be 
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entered.  If  all  users  for  an  event  have  been  entered  you 
move  on  to  the  Target  block. 

The  Target  block  covers  information  on  the  target, 
□nee  this  is  entered  you  will  move  to  the  event  Comment 
blocks.  The  first  is  for  general  comments  on  the  exercise, 
while  the  second  is  for  any  comments  that  are  classified. 

The  last  block  is  the  Lost  block  for  recording  informa¬ 
tion  on  lost  weapons  or  targets.  The  only  way  to  get  to 
this  block  is  for  a  loss  to  be  recorded  in  either  the  Weapon 
or  Target  blocks.  Upon  leaving  this  block,  you  will  either 
return  to  the  Attack  block  (if  the  item  lost  was  a  weapon), 
or  to  the  Unclassified  Comments  block  (if  the  item  lost  was 
a  target ) . 


5 .  Add  Procedures; 

This  section  explains  how  new  data  is  entered  into  the 
system.  This  is  a  general  description  of  the  process  and 
should  be  used  in  conjunction  with  the  detailed  field  de¬ 
scriptions  provided  below.  Before  entering  new  data  you 
should  have  the  exercise  summary  at  hand. 

Step  1.  Start  at  the  top  of  the  form  (If  not  at  top  of 
form,  select  Previous  Block  <page  up>  until  you  get  a  mes¬ 
sage  saying  "top  of  form"  on  the  status  line).  Select 
Create  Record  <F9>,  which  sets  up  the  form  to  enter  a  new 
record . 

Step  2.  Enter  your  exercise  type.  NuaL  the  event 
number.  Once  these  items  are  entered  you  can  select  Dupli¬ 
cate  Reco-^ci  <F7.>,  which  will  copy  pertinent  data  from  the 
schedule  into  the  Results  form  (this  may  take  10  to  15 
seconds  to  complete).  You  can  now  edit  or  accept  the  values 
copied  over  from  the  schedule. 

Step  3.  Contini.'e  to  enter  data  until  you  get  to  the  Can¬ 
celed  block.  Here,  if  no  cancellation  occurred,  leave  blank 
and  move  to  Launch  and  Recovery  assets. 

Step  4.  You  need  to  edit  the  Launch  and  Recovery  values 
copied  from  the  scheduler.  If  the  platform  was  not  avail¬ 
able,  delete  it  using  Delete  Record  <shift-F5>.  The  side 
numbers  have  to  be  changed  to  match  the  actual  side  number. 
When  finished,  select  Next  Field  <enter>  until  you  move  to 
the  next  block. 

Step  5.  You  are  now  in  the  User  block.  Enter  your  user 
data,  moving  automatically  into  Scheduled  Weapons.  When  you 
finish  entering  the  scheduled  weapons  you  will  move  to  the 
Attack  block . 
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step  6.  Enter  your  attack  data  and  attack  comments.  Once 
this  IS  complete  you  will  move  to  the  Weapon  block.  If  no 
weapon  was  fired  leave  blank,  otherwise  enter  the  informa¬ 
tion  (if  a  weapon  was  lost  see  step  8).  In  either  case  you 
will  return  to  a  blank  Attack  block.  You  may  enter  another 
attack  for  the  displayed  platform,  or  leave  blank.  Leaving 
the  field  blank  returns  you  to  the  User  block.  Again  you 
can  enter  another  user  or  leave  blank.  Leaving  the  field 
blank  takes  you  to  the  Target  block- 

Step  7.  In  Target  block  enter  the  appropriate  data  (if  the 
target  was  lost  see  step  8  ).  When  target  entry  is  complete 
you  will  move  through  the  Comment  blocks  and  then  back  to 
the  first  page  of  the  application  to  enter  additional  exer- 
c i se  r esu 1 ts . 

Step  8.  If  you  indicated  that  a  weapon  or  target  is  not 
recovered  you  will  move  automatically  to  the  Lost  block. 
Here  you  enter  data  about  the  loss.  Upon  completing  the 
block  you  will  exit  to  the  Attack  block  (if  the  item  lost 
was  a  weapon),  or  to  the  Unclassified  Comments  block  (if  the 
item  lost  was  a  target). 

After  entering  an  event  the  data  will  be  saved  and  you  will 
return  to  the  top  of  the  form.  You  can  repeat  the  process 
and  enter  another  event  cr  perform  another  operation. 


4 .  Modify  Procedures; 

Modifying  an  existing  entry  is  straightforward.  First, 
retrieve  (see  Querying  the  Database)  the  event  to  the 
screen,  then  change  or  add  data  as  if  you  were  entering  data 
for  the  first  time.  The  exception  to  this  procedure  is  that 
you  may  not  change  exercise  type  or  event  number.  To  enter 
a  new  User  or  Attack  you  must  select  Create  Record  <F9>  in 
that  block.  To  add  a  Cancellation  or  a  Support  vehicle,  /ou 
must  go  to  the  desired  block  and  select  Next  Record  <down 
arrow>  until  a  blank  line  appears,  then  enter  the  informa¬ 
tion.  To  add  an  additional  target,  go  to  the  Target  block 
and  select  Next  Record  <down  arrDw>  or  Create  Record  <F9>, 
then  enter  the  information.  To  add  additional  Comments, 
just  add  then  to  the  previous  comments.  Note,  however,  that 
blank  lines  are  not  allowed.  If  you  want  to  separate  com¬ 
ments  use  keyboard  symbols  such  as  "t",  or  to 
separate  them. 

5 .  Delete  Procedures; 

Delete  works  on  many  levels:  you  can  delete  an  entire 
event  or  any  of  its  associated  objects.  You  can  only  delete 
an  entire  event,  however,  if  it  has  no  associated  Users 


or 


Targets.  This  prevents  inadvertent  deletion  of  records. 
This  same  procedure  applies  to  User,  No  user  can  be  deleted 
if  an  Attack  is  associated  with  it. 

To  delete  an  entire  event  perform  the  following  steps: 
i)  Delete  all  Attacks  associated  with  the  Users  of  the  event 
(this  automatically  deletes  all  Attack  Comments);  (2)  Delete 
all  Users  of  the  event  (this  automatica 1 1 y  deletes  all 
Weapons  assigned  to  the  Users);  (3)  Delete  Target(s)  as¬ 
sociated  with  the  event;  and  (4)  Enter  the  Result  block  and 
select  Delete  Record  <shift-F5>,  which  automatically  deletes 
all  Comments,  Cancellations  and  Support,  along  with  the 
even  t  i tse 1 f . 

If  there  are  no  Users  and  Targets  associated  with  an 
event  to  be  deleted,  go  directly  to  step  (4). 

All  other  blocks  can  be  deleted  individually  as  shown 
in  the  SQL*FORMS  manual . 


6  .  Query  Database: 

The  ability  to  query  the  database  in  this  application 
IS  limited.  In  all  blocks  except  the  Result  block,  queries 
are  constrained  by  the  exercise  type  and  event  number  dis¬ 
played.  For-  example,  if  you  execute  a  query  in  the  Attach 
bioci-  ,  the  response  to  the  query  will  pertain  to  the  par¬ 
ticular  exercise  type  and  event  number  displayed  at  the  top 
of  tne  Attack  block.  Even  with  this  limitation,  full  queries 
max  be  performed. 

The  easiest  query  to  perform  is  a  general  query.  This 
retrieves  all  records.  To  perform  this  query,  enter  the 
Result  block  and  select  Execute  Query  <F2>.  T  ^'n  s  will 
retrieve  all  events  which  may  then  be  viewed  sequen  1 1  a  1  1  ■>  by 
selecting  Next  Record  <down  arrow> . 

The  other  type  of  query  is  a  selected  query,  through 
whirn  you  retrieve  records  that  satisfy  selected  criteria 
(For  example,  exercise  type  =  "Torpex").  This  query  is  also 
executed  from  the  Result  block.  The  general  query  procedure 
IS  as  fallows:  1)  Select  Enter  Query  <F1>;  2)  Enter  selec¬ 
tion  criteria  into  the  fields  you  wish  to  query;  and  3) 
Select  Execute  Query  <F2> .  One  example  would  be  to  find  a 
particular  exercise.  After  entering  the  Result  block,  the 
procedure  would  be:  1)  Enter  Query  <F1>;  2)  Enter  the  exer¬ 
cise  type  and  event  number;  and  3)  Select  Execute  Query 
<F2>.  This  will  either  retrieve  the  desired  record  or  sa\ 
"no  record  selected",  i  which  case,  you  can  enter  another 
que’^y.  More  complex  que-ries  are  possible  and  are  described 


in  tne  SQLfhORhlS  Operator  s  guide  chapter  11. 
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Riiult  Block  (Pigi  lit 


+ . — - - - - — . . — - + 

!  E  X  E  R  C  I  S  E  S  U  h  N  A  R  Y  I 

+ - - - - . . ♦ 

1  EXERCISE  EVENT _  EXERCISE  DESCRIPTION  _  I 


1  OPAREA  _  1 

1  COHEX  _  VISIBILITY  _  I 

;  FINEX  _  SEA  STATE  .  1 

+ . . . . — — - - ♦ 

!  REASON  CANCELED  HOURS  TINE  OF  1 

!  LOST  CANCELLATION  I 


REASON  CANCELED  HOURS  TINE  OF 

LOST  CANCELLATION 


LAUNCK/RECOVERY  ASSETS 


PLATFORH  SIDE  NUMBER  USED 


Spec  1  a  1  Keys : 

Duplicate  Record  <F7>:  This  key  copies  information  from 

the  Schedule  to  the  Results  application.  After  enter¬ 
ing  the  exercise  type  and  event  number,  press  this  key 
to  copy  the  oparea,  scheduled  comex  and  finex  into  the 
appropriate  fields.  It  will  also  list  all  the  recovery 
vehicles  in  the  launch/recovery  block. 


Fields! 

Exercise;  Enter  the  type  of  exercise.  (Standard  exercise 

types  are  available  by  selecting  List  of  Values  <F4> ) 
This  field  is  mandatory,  and  must  exist  in  the 
sc  hedu 1 e . 

Event:  Enter  the  event  number.  This  field  is  also  man¬ 

datory,  and  the  event  must  be  in  the  schedule. 

Exercise  Description:  This  field  is  automatically  filled 

in  and  cannot  be  edited. 

Oparea:  Enter  the  operational  area  in  which  the  event  took 

place. 
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Comex :  Enter  the  date  and  time  of  the  comex  in  standard 

military  date  time  group  format  DDHHMMZ  MQNYY .  Where  DD  is 
the  day  of  the  month,  HHMM  is  military  time,  Z  is  the  time 
zone  (San  Diego  is  time  zone  U),  MON  is  the  three  letter 
month  abbreviation  and  YY  is  the  last  two  digits  of  the 
year.  If  this  format  is  not  used  an  error  message  will 
appear;  select  Display  Error  <shift-F10>  to  get  a 
description  of  the  error. 

Finex:  Enter  the  finex  time  of  the  event  in  the  same 

format  as  above. 

Visibility:  Enter  the  visibility  in  nautical  miles.  Enter 

99  to  indicate  unlimited  visibility. 

Sea  state:  Enter  the  single  digit  representing  the  sea 

state . 


Canceled  Block: 

Fields: 

Reason  Canceled:  This  is  the  reason  for  which  part  or  all 

of  the  event  was  canceled.  There  are  six  valid  en¬ 
tries:  asset  availability,  fouled  range,  instrumenta¬ 

tion,  weather,  no  air  tracks,  and  no  show.  These 
values  are  available  using  List  of  Values  <F4>.  Making 
no  entry  moves  the  cursor  to  the  Launch/Recovery  Block. 

Hours  lost:  This  field  records  the  length  of  the  cancella¬ 

tion  period.  This  data  is  recorded  in  hours  and  tenths 
of  hours. 

Time  of  Cancellation:  Enter  the  time  at  which  the  cancel¬ 

lation  started.  The  format  is  the  standard  date-time 
gnoup  format  of  DDHHMMZ  MONYY .  See  comex  in  the  result 
block  for  more  details.  Once  this  is  entered  you  will 
move  to  enter  the  next  reason  canceled. 


Launch/Recovery  Block: 

Fields; 


Platform:  Enter  the  command  name  of  the  support  vehicle. 

If  Duplicate  Recc'd  was  selected  in  the  Result  block 
the  commar,a  name  will  be  filled  in  from  the  schedule. 
If  the  schedule  information  was  incorrect,  select 
Delete  Record  <shift-F5>  to  delete  the  line.  If  this 
field  IS  left  blank  you  will  move  to  the  User  Block. 
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Side  number;  Enter  the  side  number  of  the  vehicle.  The 
values  copied  from  the  schedule  have  the  letters  A,  B, 
C,  and  D.  Insert  the  correct  side  number. 

Used;  A  Y/N  entry  indicating  whether  or  not  the  vehicle 
was  actually  used  to  support  the  event.  If  it  stayed  in 
port  or  on  the  ground  the  answer  is  N.  If  the  vehicle 
was  broken  or  not  available  then  it  should  not  be 
listed.  After  entering  this  field  you  will  move  to  the 
next  platform  in  the  list. 

Uiir  Block  (Pigi  2)i 


♦ - 

;  EXERCISE 
♦ - 


USER  DATA 

- - - - - 


4 


COHHAND  DESI6NATI0N  _  SIDE  NUMBER 

SHONED  FOR  EXERCISE  _  TRACX  OUALITV 

SONQBUOY  USASEi  LOFAR  _ 

DIFAR  _ 

DICAS  _ 

VLAD  _ 


NEAPON  TYPE  NUMBER  REASON 

SCHEDULED  NOT  DROPPED 


Fie  Ids ; 


Exercise;  This  field  is  replicated  from  the  exercise  type 
and  event  number  fields  of  the  Result  block  and  cannot 
be  entered . 

Command  Designation:  The  name  of  the  command  using  the 

range.  The  name  is  the  standard  Navy  designation  for 
the  command  ( ie  VP— 44  or  SSN-600).  For  consistency 
include  the  hyphen.  If  this  field  is  left  blank,  the 
system  assumes  you  have  entered  all  the  commands  in¬ 
volved  in  the  event  and  you  move  to  the  Target  Block. 
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Side  number:  This  field  is  only  entered  if  the  command  was 

an  aircraft  squadron.  Enter  the  side  number  of  the 
actual  aircraft  that  used  the  range.  If  a  squadron  was 
scheduled  for  two  aircraft  and  one  did  not  show  enter  a 
NS  for  no  show. 

Showed  for  exercise:  A  Y/N  entry  indicating  whether  or  not 
a  scheduled  user  showed  up  for  the  event. 

Track  quality:  Enter  the  quality  of  the  track  observed  by 

the  range,  from  0  (no  track)  to  100  (a  perfect  track). 
After  entering  this  field  aircraft  move  to  the  sonobuoy 
field;  all  others  go  directly  to  Scheduled  Weapons. 

Sonobuoy  Usage:  These  four  fields  record  how  many  buoys  an 

aircraft  uses.  Enter  the  number  of  buoys  used  for  each 
type.  When  exiting  the  last  field,  you  will  move  to 
the  Weapon  block. 

Weapon  Block: 

Fields: 

Weapon  type:  Enter  the 

NK-46  or  NK-48.  The 
and  copy  the  number 
field.  If  this  field 
the  Attack  block . 

Number  scheduled:  This  field  records  how  may  weapons  were 

originally  scheduled.  The  total  number  of  weapon  type 
scheduled  for  a  command  is  copied  into  this  field.  For 
aircraft  squadrons,  this  number  needs  to  be  verified 
because  the  weapons  may  have  been  divided  equally  among 
all  pi atf orms . 

Reason  Not  Dropped:  A  code  indicating  why  all  scheduled 

weapons  were  not  dropped.  The  codes  are:  A)  platform 
problems,  B)  torpedo  problems,  C)  weather,  D)  inade¬ 
quate  recovery  assets,  E)  time  constraints,  F)  fouled 
range,  G)  inadequate  TNA,  H)  pinger  problem,  and  1) 
other.  After  entering  this  data  you  will  be  able  to 
enter  the  next  weapon  scheduled  for  this  platform. 


type  of  weapon  scheduled,  either 
system  will  search  the  Schedule 
scheduled  into  the  appropriate 
is  left  blank,  you  will  move  to 
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Attack  Block  (Pigo  3)i 


ATTACK 

DATA 

EkERCISE  _ 

COHHAHS 

SIDE  NUMBER 

1 

» 

TOF 

START  ATTACK  RUN 

TAR6ET  DATA 

SOLUTION  DATA 

!  FIRING  UNIT  DATA 

1 

COURSE  _ 

COURSE  _ 

!  COURSE  _ 

BEAR1N6 

BEARIN6  _ 

1  SPEED  _ 

RAN6E 

RANGE  _ 

!  ALTITUDE  _ 

SPEED  _ 

SPEED  _ 

i 

1 

DEPTH 

+ - ........... — 

DOPPLER  _ 

1 

1 

MANEUVER  1 

1 

i 

TIME  + - 

COURSE  _ 

SPEED  _ 

- - + 


Fie  Ids ; 

Exercise:  Replication  of  exercise  type  and  event  number. 

Command:  The  command  that  conducted  the  attack. 

Side  number:  The  side  number  of  the  platform  that  per¬ 

formed  the  attack  (if  applicable). 

TOF :  Time  of  Fire.  The  time  that  the  weapon  was  launched. 

This  identifies  the  attack.  The  time  must  be  entered 
in  standard  military  date-time  group  format  DDHHMMZ  - 
MDNYY  .  See  Result  block  comex  for  more  information  on 
date-time  format. 

Start  Attack  Run:  Enter  the  time  at  which  the  platform 

starts  searching  for  the  target.  This  also  has  to  be 
entered  in  standard  date-time  group  format  DDHHMM  MON- 
YY  . 

Target  Course:  Enter  the  course  of  the  target  at  TOF 

[recorded  in  degrees  true  (0-359)]. 

Target  Bearing:  Enter  the  true  bearing  from  the  platform 

to  the  target  at  TOF  (0-359). 

Target  Range:  Enter  range  from  platform  to  target  at  TOF 

in  yards. 
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Target  Speed:  Enter  the  speed  of  target  at  TOP  in  kts. 

Target  Depth:  Enter  the  depth  of  the  target  at  TOP  in 

feet . 

Maneuver  time:  The  time  in  minutes  after  TOP  at  which  the 

target  maneuvered.  The  time  is  recorded  in  minutes  and 
tenths  of  a  minute.  Enter  0  if  no  maneuver  after  TOP. 
Enter  0.1  if  maneuver  occurred  at  TOP.  If  0  is  entered 
the  maneuver  course  and  speed  are  skipped. 

Maneuver  course:  The  new  course  after  the  maneuver  [recor¬ 

ded  in  degrees  true  (0-359)]. 

Maneuver  speed;  The  new  speed  of  the  target  in  kts  after 
the  maneuver. 

Solution  Course:  The  firing  solution  course  [measured  in 

degrees  true  (0-359)]. 

Solution  Bearing:  The  firing  solution  bearing  (0-359). 

Solution  Range:  The  firing  solution  range  in  yards. 

Solution  Speed:  The  firing  solution  speed  in  kts. 

Doppler:  A  code  entered  to  describe  the  amount  of  target 

doppler  the  firing  craft  was  reading.  The  codes  are: 
1)  doppler  >  +5  kts,  2)  doppler  between  +2.5  and  +5 
kts,  3)  doppler  between  -2.5  and  +2.5  kts,  4)  doppler 
between  -2.5  and  -5  kts,  5)  doppler  <  -Skts. 

Firing  Unit  Course;  Course  of  platform  at  TOP  [measured  in 
degrees  true]. 

Firing  Unit  Speed;  Speed  of  platform  at  TOP. 

Firing  unit  Altitude;  Altitude  of  aircraft  at  TOP.  This 

field  is  skipped  for  ships.  After  entry  you  will  move 
to  the  next  page  and  continue  entering  attack  informa¬ 
tion. 
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Attack  Block  (Pigt  4)i 


EXERCISE 


ATTACK  DATA 
UNIT  _ SIDE  NUHBER 


TOP 


FIRIN6  DATA 

CONTACT  TYPE 
ATTACK  NODE 
SONAR  SETTING 
DELIVERY  NODE 
SEARCH  DEPTH 


RESULTS 

ACQUIRED 
ATTACK  EVAL 
PH 

SPLASH  BEAR I NS 
SPLASH  RANGE 


ATTACK  CONNENTSt 


4 


Fields ; 

Exercise,  Unit,  side  number,  TOF ;  These  fields  are  not 
entered;  replicating  earlier  recorded  data. 

Contact  Type;  Enter  the  sensors  used  to  develop  the  firing 
solution.  There  are  13  legal  values  which  can  be 

viewed  using  List  Values  <F4>. 

Attack  Mode;  Enter  how  the  torpedo  was  programmed  to 

perform  its  attack  (either  circle  or  snake). 

Sonar  Setting;  Enter  the  type  of  sonar  the  torpedo  used. 

There  are  four  settings  available  and  may  be  viewed 
using  List  Values  <F4>. 

Deliver  Mode:  Enter  how  the  weapon  was  launched.  There  are 

six  different  delivery  modes  which  may  be  viewed  using 
List  Values  <F4>. 

Search  Depth:  The  depth  at  which  the  weapon  starts  its 

search,  in  feet. 

Acquired;  How  many  times  did  the  weapon  acquire  the  tar¬ 

get.  If  it  did  not  acquire  enter  0,  If  it  acquired  the 
target  more  than  nine  times  enter  9. 

Attack  Eval:  Evaluation  of  the  attack.  There  are  five 

legal  values,  HIT,  MISS,  PROB  HIT,  PR0B,MISS,  UNKNOWN. 
These  values  are  also  available  using  List  Values  <F4>. 
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If  the  platform  that  launched  the  attack  Mas  not  an 
aircraft  you  Mill  automatically  skip  to  Attack  Comments 

E  1  c  ■ 

PH;  Enter  the  decimal  value  of  the  Probability  of  Hit 

(0.00  to  1.00). 

Splash  Bearing:  The  relative  bearing  from  the  target  to 

the  splash  point  (0-359). 

Splash  Range:  Range  from  target  to  splash  point,  in  yards. 

After  entering  this  field  you  Mill  move  to  Attack 
Comments  Block. 


Attack  Comments  Block: 

Fields: 

Comments:  This  field  allOMS  you  to  enter  comments  that 

pertain  to  the  specific  attack  shoMn  at  the  top  of  the 
screen.  Select  return  at  the  end  of  each  line  to  move 
to  the  next  line.  Selecting  return  twice  Mill  move  you 
to  the  Weapon  Block. 


Ntipon  BlocI:  (Pigi  S)t 


M  E  A  P  0  N  DATA 

♦ - - - - . + 

;  E)lERClSE _ UNIT  _  SIDE  NUMBER  _  TOP  _  I 

♦ . — - — — - — — - - - 

NK  _  HOD  _  SERIAL  _ 

TRACK  QUALITY  _  TORPEDO  PERFORHANCE  _ 

NEAPON  RECOVERED(Y,N) 

SEARCH  TIME  _  RECOVER  VEHICLE  _ 

TIHE  TO  RECOVER  BRINS  BACK  VEHICLE  _ 


Fields; 

Exercise,  Unit,  Side  Number,  TDF :  These  fields  are  not 

entered,  but  are  replicated  from  earlier  data. 
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MK:  Enter  the  MK  of  the  weapon,  enter  MK-48,  MK-46  or  any 

other  weapon  used.  If  no  weapon  was  launched  as  in  a 
siiT.ulated  attack,  leave  fclanl-.  and  you  return  to 

the  attack  block  to  enter  another  attack. 

MOD:  Enter  the  mod  of  the  weapon. 

Serial :  Enter  the  serial  number  of  the  weapon  (up  to  seven 

characters  long). 

Track  Quality:  Enter  the  quality  of  the  weapon  track  from 

0  to  100. 

Torpedo  performance:  Enter  the  performance  of  the  weapon. 

There  are  six  legal  values  which  may  be  selected  by 
using  List  of  Values  <F4>. 

Weapon  Recovered:  This  field  indicates  if  the  weapon  was 

recovered  or  not.  If  N  is  entered,  you  will  move 

directly  to  the  Lost  block.  If  Y  is  entered,  you  will 
continue  entering  data  in  this  block. 

Search  Time:  Enter  into  this  field  the  number  of  seconds 

that  the  weapon  was  in  the  search  mode. 

Recover  vehicle:  The  vehicle  that  picked  up  the  weapon 

(i.e.,  TWR-789  or  HC-1  345). 

Time  to  Recover:  Enter  the  length  of  time  between  when  the 

weapon  stopped  running  and  when  it  was  retrieved. 
Measured  in  minutes. 

Bring  Back  Vehicle:  The  vehicle  that  returned  the  weapon 

to  San  Diego.  After  entering  this  field  you  will  move 
back  to  the  attack  block  to  allow  entry  of  another 
attack  by  this  platform. 


138 


Tirgtt  Block  (Pigi  61 t 


T  A  «►  6  E  T  ;  A  T  A 


+ - f 

:  EXERCISE  _  ! 

I - ^ 

TAR6ET  DESIfiA'ATION  _  HOD  _  SERIAL  HUHBER  _ 

LAUNCH  TIHE  _  TRACK  QUALITY  __ 

PERFORMANCE  _  BEOHETRY  _ 

SOUND  LEVEL  _  FREQUENCY  BAND  _ 

RECOVERED(Y,N)  _  RECOVERY  VEHICLE  _ 


Fields ! 

Exercise:  This  field  is  not  entered,  but  replicates  exer¬ 

cise  type  and  event  number. 

Target  Designation:  If  the  target  is  a  ship  or  submarine, 

enter  its  command  name.  For  a  mechanical  target  enter 
the  MK,  If  a  ship  or  submarine  is  entered  the  remain¬ 
der  of  the  block  is  not  applicable,  and  you  move  to 
the  Comments  blocks. 

Mod:  Enter  the  mod  of  the  target. 

Serial  Number:  Enter  the  serial  number  of  the  target. 

Launch  time:  Indicate  the  target  launch  time  in  standard 

date-time  group  format  DDHHMMZ  MONYY.  See  the  Comex 
field  in  the  Results  block  for  more  information  on  the 
date-time  format. 

Track  quality:  Enter  the  quality  of  the  target  track 

during  the  event  (0  -100). 

Performance:  Enter  the  target  performance.  There  are  six 

legal  values  which  may  be  viewed  by  selecting  List 
Values  <F4>. 

Geometry:  Enter  the  geometry  that  was  used  by  the  target. 

Sound  Level:  Enter  the  average  sound  level  generated  by 

the  target  (measured  in  DB )  . 
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Frequency  Band:  Enter  the  type  of  sound  generated  t/  the 

target.  The  two  legal  values  are  NB  for  narrow  band 
and  BB  f'-'r  broad  band. 

Recovered:  This  is  a  Y/N  field  indicating  if  the  target 

was  recovered.  If  it  was  not  recovered,  you  will  move 
to  the  Lost  block. 

Recovery  Vehicle:  The  vehicle  that  recovered  the  target. 

After  entering  this  field  you  will  move  to  the  Unclas¬ 
sified  Comments  block. 


Uncliiilflid  CoMinti  Block  (Pigi  7)i 

UNCLASSIFIED  C  0  N  N  E  N  T  S 
+ - - - - - - - - - - - ♦ 

!  EXERCISE  : 

♦- - - - - + 

conncNTS 


Fields : 

Comments:  Enter  general  comments  about  the  event.  The 

comments  may  be  as  many  lines  as  needed.  Use  <Enter> 
to  move  to  the  next  line.  Pressing  <Enter>  twice  will 
move  you  to  the  Classified  Comments  block. 


Classified  Comments  Block  (Page  8): 

This  block  is  identical  to  Unclassified  Comments  but  is 
for  classified  comments.  Selecting  <Enter>  twice  will 
move  you  back  to  the  top  of  the  form  (Result  block). 


1^0 


Loit  Block  (Pigi  9)i 


lost  targets  and  N  E  a  P  0  N  S 


♦ - - - - ♦ 

!  EXERCISE _ Hk _  NOD _  SERIAL  MUHBER _  1 

I  TOP  _  ! 

♦ — - - + 


TINE  OF  LOSS 
LATITUDE 
LONGITUDE 
INPLOSION  DEPTH 
NATER  DEPTH 


Special  Keys: 

Previous  Block  <page  up>:  This  will  return  you  to  the 

block  from  which  you  came  (Weapon  or  Target). 

Next  Block  <p?ge  down>:  This  will  save  the  data  in  the 

Lost  block  and  move  you  back  to  Attack  (if  the  item 
lost  was  a  weapon),  or  to  the  Unclassified  Comments 
block  (if  the  item  lost  was  a  Target). 

Fields: 

Time  of  Loss;  Enter  the  time  that  tne  loss  occurred  in 

standard  date-time  group  format  DDHHMMZ  MONYY .  This 
field  also  has  special  definition  for  the  Previous 
Field  <shift-tab>  key.  If  you  enter  Previous  Field 
<shift-tab>  the  system  assumes  that  you  made  a  mistake 

and  deletes  the  loss  and  moves  you  to  the  block  from 

where  you  came.  If  you  leave  the  field  blank,  you  will 
also  return  to  the  block  from  where  you  came. 

Latitude:  Enter  the  latitude  where  the  loss  occurred. 

Longitude:  Enter  the  Longitude  where  the  loss  occurred. 

Implosion  depth:  Enter  the  depth  at  which  it  imploded,  in 

feet  (if  unknown,  enter  0). 

Water  Depth:  Enter  the  depth  of  the  water  where  the  loss 
occurred  (in  feet).  After  entering  this  field  you  will 
either  return  to  the  Attack  block  or  advance  to  the 
Unclassified  Comments  block. 
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APPENDIX  L 


SAMPLE  REPORTS 


A.  Sample  Brief  Reports 


BRIEF  REPORT 


TITLE 

LlAlt 

TIME 

LOCATION 

BRIEFER 

PRE 

AUD 

HE 

AUD 

HERE 

HE 

PRE 

A122 

HE 

PRE 

A122 

HE 

POST 

12  HAR 

1900 

IS-300 

HE 

BRIEF  REPORT 


title 

DATE 

TIHE 

LOCATION 

BRIEFER 

PRESAIL 

06  JUN 

1100 

AUD 

YOU 

PRE 

AUD 

HE 

AUC 

HERE 

HE 

FER-BRIEF 

AUD 

HIH 

PREBRIEF 

03  HAR 

1700 

AUD 

PJD 

POST-SAIL 

SHIP 

DR 

PRE 

A122 

HE 

POST 

1-322 

DR 

PRE 

A122 

HE 

POST 

AUD 

YOU 

THESIS 

HERE 

DJR 

POST 

12  HAR 

1900 

IS-300 

HE 

143 


B. 


Sample  Meekly  Schedule 


WEEKLY  SCHEDULE 

PERSONNEL  TRACKINS  SUPPORT  VEHICLES 


EXERCISE  TITLE 

COHEX-FINEX 

OPAREA 

PE  OC  OA  60 

EATS  1/N 

PfilTST  SECT8T  PfilNEP  8ECNEP 

NONDAT  13  HAR  Sf 

AE12  B9082  TORPEX 

131200-131700 

SOAR 

A  /B  /C  /D 

X 

X 

TNR 

TNR 

HC-1 

HC-1 

A60i  89001  TORPEX 

131900-132200 

AREAl 

/  /  / 

X 

X 

T 

T 

H 

H 

TUESDAY  14  HAR  89 

A601  89002  TORPEX 

140700-141855 

AREAl 

A  /B  /C  /D 

X 

X 

HCl 

HC-1 

TRN 

TNR 

A601  89004  TORPEX 

141300-081600 

AREAl 

!  1  / 

X 

X 

H 

TC 

TBY 

NEDNESDAY  IS  HAR  89 

A612  89083  TORPEX 

151400-141800 

SOAR 

F3/HN/PD/DR 

X 

X 

HC-1 

TNR 

HC-1 

TNR 

THURSDAY  16  HAR  89 

A601  89005  TORPEX 

160730-161300 

CASTl 

NN/RD/TN/RT 

X 

X 

HC-1 

TNR 

HC-1 

TNR 

FRIDAY  17  HAR  89 

HOOO  89001  HAINTENANCE 

171230-171700 

SOAR 

H»/H  /  / 
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